Databricks on Oct. 7 announced that on-behalf-of-user (OBO) authorization for Databricks Apps is now generally available. On-behalf-of-user authorization means a supported request from an app runs with the identity of the person signed in to it. For those requests, that person's own data permissions decide what the app can return. Separate API (application programming interface) scopes limit what the app is allowed to do for that user.
Key facts from the announcement
- Status: Generally available for Databricks Apps.
- Identity: Supported requests run with the signed-in user's identity.
- Data rules: Unity Catalog, the platform's data-permission system, applies the user's existing permissions, including row filters and column masks.
- Limits: API scopes restrict the operations an app can perform for the user.
- App-owned work: Apps can keep using their own service principal for tasks such as reading shared configuration or writing application metrics.
Why it matters
Databricks says the main benefit is personalized, permission-aware apps built without rewriting data-governance rules in application code. Data governance is the set of rules that decide who may see which data. Under OBO, those rules stay in Unity Catalog. The app passes along the user's identity. Unity Catalog then applies that user's existing permissions to the request. Row filters hide the rows a user is not allowed to see. Column masks can redact or transform sensitive values inside a column. Two people can open the same app and get different results, each limited to their own access.
How a user-authorized request works
The announcement describes the flow in a few steps. First, a person signs in and uses the app. Next, Databricks forwards that user's access token to the app in an HTTP header named x-forwarded-access-token. An access token is a temporary credential that proves who the user is. HTTP (Hypertext Transfer Protocol) headers are labeled fields sent along with a web request. Then the app uses the token for a supported request, so the request runs as that user. The token is short-lived and tied to a single request. In the example code, the app reads it on each request. It never stores the token across requests or in a session.
Choose the identity for each operation
Databricks Apps offers two ways for an app to identify itself. App authorization uses the app's dedicated service principal. A service principal is a non-human account that holds the app's own permissions. User authorization, the OBO model, uses the signed-in person's identity instead. Databricks says most production apps can use both models and choose the identity for each request path. A request path is one route through the app, such as a single page or function. The service principal remains the choice for app-owned work, such as reading shared configuration or writing application metrics.
Which identity should run the request?
Which identity does Databricks describe for user-specific, app-owned and mixed operations, and what is an example of each?
| Operation | Identity used | Example from the announcement | Source |
|---|---|---|---|
| Governed data for the current user | Signed-in user (OBO), limited by API scopes and the user's Unity Catalog permissions | Read-only queries using the sql:restricted-query scope | Source: Now GA: Building permission-aware Databricks Apps with on-behalf-of-user… (databricks.com), Oct 7, 2026 |
| App-owned operations | The app's dedicated service principal | Reading shared configuration or writing application metrics | Source: Now GA: Building permission-aware Databricks Apps with on-behalf-of-user… (databricks.com), Oct 7, 2026 |
| Apps with both kinds of work | Both models, with the identity chosen for each request path | Service principal for metrics, user identity for governed queries | Source: Now GA: Building permission-aware Databricks Apps with on-behalf-of-user… (databricks.com), Oct 7, 2026 |
The rows follow the examples in the Databricks announcement and do not assess any particular app or workspace setup.
How to configure it
Setup involves two roles, according to the announcement. Developers add API scopes to an app. Workspace administrators can control which scopes developers are allowed to add in that workspace. A workspace is a team's shared Databricks environment. For an app that only needs to read data, the matching scope is sql:restricted-query. It allows the app to run read-only SQL (Structured Query Language) queries. The app then uses the forwarded user token for those queries, so each one runs as the person asking.
Analysis: scopes are not data permissions
Databricks calls scopes "a capability ceiling, not a grant of data access." A request under OBO has to clear two separate checks. The app must hold the right API scope. The user must also have permission for the target resource. One reading is that the two checks answer different questions. The scope sets what the app may do with a user's identity. Unity Catalog sets what that user may see. A read-only scope does not widen anyone's view of the data. A user with broad permissions still cannot push the app past its scopes. The workspace control adds a further limit, set by administrators rather than by each developer.
Limitations
The general-availability status and the technical details come only from Databricks, which gives no adoption figures or rollout dates.
Where to go deeper
The full Databricks announcement covers request-time token handling and workspace scope controls in more depth, including code for a first user-authorized app.
ZIPMEX promotes trading on trade.zipmex.com. Promotions are labelled and kept separate from news coverage, which is selected and checked without regard to them. Perpetual futures are leveraged derivatives. Prices can move fast and you can lose all of your margin. Not available in every jurisdiction. Not investment advice.
