The same sales assistant can answer a regional manager and a national executive without giving them the same view of company data. The difficult part is preserving that distinction after a request leaves the interface and becomes SQL, a model call or an agent’s tool invocation.
Databricks made user authorization for Apps generally available on October 7, 2026, after more than 18 months of public preview. On-behalf-of-user authorization, or OBO, lets supported requests execute with the signed-in person’s identity instead of routing every action through the application’s own service principal. Existing Unity Catalog controls can follow the person into the request. That is a meaningful reduction in duplicated policy code, not a promise that delegation automatically makes an app safe.
A production release for a second identity path
Databricks Apps runs data applications, dashboards, operational tools and custom agents on serverless infrastructure. Each deployed app receives a dedicated service principal: a nonhuman identity with permissions granted to that instance. This application authorization remains useful for common configuration, telemetry, maintenance and automated work.
User authorization adds another path rather than replacing it. Databricks forwards an access token to the runtime for a supported action initiated by an authenticated person. The app can then call an approved Databricks API under that user’s permissions. The OAuth 2.0 model distinguishes user-to-machine delegation from machine-to-machine work.
For governed data, Unity Catalog evaluates existing grants, row filters and column masks. Warehouse permissions separately determine whether the requested query can execute. A regional manager can see one territory while a national leader sees more, through the same application path. Later requests are evaluated against updated catalog policies rather than a separate app-maintained copy.
That avoids a common source of drift. A shared app identity exposes one permission set to the backend; developers then reconstruct which results belong to each employee through roles, mappings, middleware or another policy service. Those controls can work, but a catalog change and an unchanged local mapping can expose information or deny legitimate access.
The Apps OBO public preview began on March 26, 2025, covering resources including Unity Catalog tables and model-serving endpoints. GA signals production readiness within documented limits. It does not mean every cloud, region, workspace, compliance profile or downstream API is universally supported. The source notes a late-September 2026 rollout indication for compliance-security-profile workspaces; customers still need to confirm their environment.
An app can use its own identity to read shared instructions and record metrics, then the current user’s identity for customer and sales records. Authentication establishes who is present. Authorization determines what that identity may do downstream. Confusing the two would miss the release’s main contribution.
The user’s grants and the app’s scopes must intersect
OBO does not give someone access to a table or warehouse merely because an app asks for it. The person must already hold the necessary resource permissions. Developers also declare API scopes, limiting which classes of operation the app can perform on that person’s behalf.
These are two separate boundaries. A scope does not create a new data grant; it constrains how the app exercises existing access. Databricks documents sql:restricted-query for read-only SQL analysis, allowing restricted queries as the current user without broad warehouse administration or unrelated administrative work.
This matters particularly for privileged users. An executive or administrator may legitimately access many sensitive datasets, but a narrowly scoped app should not inherit every capability that person could exercise directly. Scopes reduce available operations even when the user’s own access is extensive.
Workspace administrators set a further ceiling on scopes developers may add. The allowlist can permit all supported APIs, selected scopes or no user authorization. The announcement says the default can include all supported APIs, so this is a governance choice rather than evidence of a restrictive baseline.
There are important exceptions to the apparent ceiling. Account administrators can add scopes excluded by a workspace allowlist. Removing a previously allowed scope also does not immediately stop existing apps: they can continue running. An affected app cannot subsequently start, deploy or update until the disallowed scope is removed.
Consequently, changing an allowlist is not equivalent to instantly revoking every running use. Administrators need deployed-app inventories, scope ownership and business dependencies to understand the transition and avoid a surprise block at the next deployment. A constrained baseline and documented exception route are more useful than an assumption that configuration alone settles enforcement.
Tokens belong to a request, not to the whole agent
The application must keep user-scoped and app-scoped clients distinct. Governed interactive queries belong on the user path; shared configuration and work continuing without a user session belong on an appropriately limited app path. Separate dependencies and handlers make accidental credential use easier to detect than a generic client that hides its principal.
When a route requires user authorization and the forwarded token is absent, it should reject the request. Silently falling back to the service principal can produce a technically valid answer with entirely different access, broader or narrower than expected. Users may not see any indication that the identity changed.
Forwarded tokens should never be printed, logged or persisted. For custom agents deployed through Apps, Databricks says the user-scoped workspace client must be initialized inside the active invoke or stream handler. The token exists only while the request runs, not during global application startup.
One agent process can serve many people. Treating a user’s identity as global state risks missing or mixing request context. A multistep workflow might retrieve common instructions as the app, query governed financial data as the user, then write general telemetry as the app without retaining the user credential. Each transition needs an explicit principal and scope.
Long-running or delayed work creates another boundary. A task initiated by a user can outlive its request, but that is not permission to save the forwarded token. Work belonging to the app needs a narrowly authorized service principal. Work requiring user context needs another documented, supported delegated pattern rather than credential retention.
Nor does OBO automatically cross every external integration. A downstream service must support the model and may require separate credentials, consent, scopes and audit controls. Tokens have a particular audience and purpose; Microsoft’s OBO guidance likewise warns against relaying middle-tier tokens to unintended recipients. This is bounded delegation, not blanket impersonation across a tool chain.
Opening the application is not permission to read its data
Databricks Apps is not an anonymous public-app model. Users must authenticate; external collaborators require onboarding through supported identity federation. The natural audience is a managed workforce or partner population, not unrestricted anonymous visitors.
Within that audience, CAN USE and CAN MANAGE govern who can run or administer the application. They do not grant its underlying tables, records or warehouse access. Someone can be allowed to open an app but receive a denied or restricted data response. Conversely, a table grant does not necessarily authorize opening the app.
Those controls therefore need separate review from Unity Catalog grants. A correctly delegated SQL request can still be combined in the interface with a file request accidentally executed as the app. Platform enforcement cannot ensure that developers assign the intended identity to every code path.
Agents amplify this risk because they interpret open-ended questions, choose tools and construct queries across multiple steps. A prompt injection in retrieved content may encourage disclosure or an inappropriate action. OBO limits accessible data to the current user, but neither a valid identity nor a read-only scope proves that every permitted query serves that user’s intention.
Consent also does not replace administrative review. People may approve scopes without understanding how services and results will be combined. Input handling, tool constraints, output controls and runtime monitoring remain necessary, including scrutiny of unusual queries, repeated denials, unexpected volumes and changed app behavior.
Testing only with an administrator can hide defects because that account encounters few denials. Regional, broader-access and no-table-access users reveal different outcomes; both data and rejection behavior matter. Databricks recommends repeating tests after governance changes. Logs should distinguish app actions from actions for a person without recording bearer tokens or sensitive response contents.
Less duplicated policy, more dependence on the platform
Delegation cannot repair excessive source grants. Groups, catalog privileges, warehouse access, row filters and masks still need accurate maintenance. A searchable technical knowledge base can preserve threat models, authorization decisions and review evidence alongside implementation documents, but documentation is not enforcement.
Databricks’ distinction is the integration of delegated identity with its governed data, SQL and application runtime, not the invention of delegation. Microsoft already documents OBO across APIs. Google’s identity-aware access emphasizes hosted applications and contextual policy, while AWS offers authorization components for custom systems. These approaches assign different integration responsibilities to platforms and developers.
For data already governed in Unity Catalog, the Databricks approach can reduce translation work between security teams and application frameworks. The trade-off is tighter dependence on Databricks-specific scopes and identity behavior. Multicloud resources can still need another authorization layer.
No independent benchmark establishes development-time savings or the rate at which enterprises avoid permission defects. Production patterns serving genuinely different users, auditable mixed-service workflows, finer scopes and clearer consent would provide stronger evidence than GA language alone. Token incidents, scope sprawl or identity fallback bugs would weaken the case.
The release removes a barrier to production adoption while leaving the central architectural choice visible: which operations belong to the application, and which belong to the person? Its value depends on maintaining that distinction as SQL, agents, files and external services become one product—not on treating a signed-in user as an unlimited credential.
Sources and related reading
Databricks GA announcement; Apps authorization model; March 2025 preview release; Microsoft OBO guidance; related reading on searchable technical knowledge bases; Apps permission levels; Google identity-aware access.