> ## Documentation Index
> Fetch the complete documentation index at: https://docs.basic.tech/llms.txt
> Use this file to discover all available pages before exploring further.

# Managing permissions

> How users will be able to manage permissions to their data

<Info>
  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.
</Info>

# 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
   <Note>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)</Note>
4. The application then uses this token to make requests to the user's datastore.
   <Note>The application simply includes the token as an auth header in its API requests</Note>

### 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](http://ucan.xyz/)