Skip to main content
Permission UX and fine-grained scope strings continue to evolve. Treat this page as the conceptual model; exact scope names and dashboard controls may change—verify against your project settings and the live OAuth flow.

​
How it works

Users sign in and grant scopes to your app. Access tokens encode what the app may do. Users can revoke access from their account when they no longer trust an app.

​
Flow

  1. Application initiates login / auth flow, which redirects users to a Basic SSO page
  2. User can select how much access they want to give
  3. The scope is defined into a self-verifiable token (JWT) that is sent to the application
    The token is cryptographically signed and is verifiable (i.e., it cannot be forged, and developers can independently verify that it came from the respective users)
  4. The application then uses this token to make requests to the user’s datastore.
    The application simply includes the token as an auth header in its API requests

​
Scope

Usually, an application will specify what it wants to request. At minimum, this is set to profile to return general profile info. Scope can be extended to include access to the database, which is organized in the following hierarchy: database > table > row > field. For example, an application might request the following scope:
  • profile
  • database_id.table_id = read
  • database_id.table_id.row_id = read, write
In this example, the application can read anything under a specified table in the database, but only has write access to one row/object. This process is modeled after UCANs