Databricks Apps gets on-behalf-of-user authorization, now generally available

Databricks has made on-behalf-of-user (OBO) authorization generally available for Databricks Apps, allowing apps to call supported Databricks APIs with the signed-in user's identity. According to the company, developers can build permission-aware apps without reimplementing data-governance rules in application code.
- On-behalf-of-user (OBO) authorization for Databricks Apps is now generally available, according to Databricks.
- Apps act as the signed-in user, and Unity Catalog enforces row filters and column masks.
- Databricks recommends the narrow sql:restricted-query scope for read-only analytics instead of the broader sql scope.
- Workspace administrators can limit which API scopes apps may request, or disable user authorization entirely.
- Apps should never store user tokens and should fail closed if the forwarded token is missing.
How OBO works in Databricks Apps
Databricks Apps lets developers build and deploy data and AI applications directly on the Databricks platform, from interactive dashboards and operational tools to custom AI agents. With OBO, an app that calls supported Databricks APIs acts as the signed-in user. Unity Catalog enforces that user's existing data permissions, including row filters and column masks, while API scopes limit the operations the app can perform on the user's behalf.
Apps can still use their dedicated service principal for app-owned operations, such as reading shared configuration or writing application metrics. Databricks describes two complementary models: app authorization, which uses the service principal and suits operations that should return the same result to every user, and user authorization, which applies when the user's permissions should govern an operation. According to the company, most production apps can use both, choosing the identity for each request path.
Databricks gives the example of a sales-insights assistant that answers questions using only the accounts and fields a salesperson is authorized to access, without broad SQL or workspace-administration capabilities. A regional manager might see only accounts in their region, while a national leader sees all regions, with no need to recreate those rules in code. When administrators update Unity Catalog policies, later app requests reflect the changes.
Narrow scopes and the forwarded token
Databricks advises using the narrowest API scope that fits the job. For a read-only analytics assistant, it recommends sql:restricted-query instead of the broader sql scope. The narrower scope allows read-only SQL queries and nothing else, so the app cannot use the user's identity as a broad SQL operating credential. If an app also calls Genie or Unity Gateway for the user, Databricks says to request only the matching scopes, such as genie or ai-gateway, and not to request files, model-serving or vector-search unless the app uses them.
Scopes set a ceiling and do not grant access. The user must still have permission to use the target SQL warehouse and the required Unity Catalog privileges. Developers can configure user authorization in the Databricks UI or in a Declarative Automation Bundle, and users are prompted to consent to the requested scopes when they first open a user-authorized app.
Databricks forwards the current user's access token in the x-forwarded-access-token HTTP header. The app retrieves it for the request that needs user-context access and passes it to the SQL connector through access_token. The company's example uses Flask and the Databricks SQL Connector for Python, and says the same principle applies to apps built with Databricks AppKit. The token is short-lived and per-request, and the app should read it on each request and never store it across requests or in a session.
Admin limits and separating identities
Workspace administrators can set the upper boundary for scopes. Under Settings > Development > Apps, the allowlist defaults to all supported APIs, can be narrowed to selected scopes, or can be set to None to disable user authorization. Developers cannot expand an app's authorization beyond that boundary. Account administrators can add scopes even if they are not in the workspace allowlist. If an allowed scope is later removed, running apps that use it can continue, but they cannot be started, deployed or updated until the non-allowed scope is removed.
Databricks also recommends keeping app-owned and user-owned operations apart in code, with an app client for the former and a user client for governed operations. Separate dependencies, names and tests help prevent an app credential from being used on a user-specific path, or a user token from being kept for background work. If a request needs user authorization and the forwarded token is missing, the app should fail closed.
What it means for developers and admins
For teams building data apps and AI agents on Databricks, the GA release means existing Unity Catalog rules can govern what an app returns for each user, rather than being rewritten in application logic. Administrators keep control through the workspace scope allowlist, while developers declare the minimum scopes their apps need.


