Databricks announced on 7 October 2026 that on-behalf-of-user authorization in Databricks Apps is generally available. An app can now call supported Databricks APIs using the identity of the person signed into it, so Unity Catalog enforces that user's own permissions, including row filters and column masks, and API scopes bound what the app is allowed to do on their behalf.
The permission model stops being copied into app code #
The pattern this replaces is familiar to anyone who has shipped an internal tool on a data platform. The app connects as a service principal with wide read access, and the developer then writes a second layer of filtering in Python or in a WHERE clause to decide which rows this particular person should see. Two permission models, one of them maintained by a governance team and one of them maintained by whoever last touched the app. They drift, and the drift is invisible until someone sees a number they should not have seen.
With OBO the grants in Unity Catalog are the grants the app obeys. A sales-insights assistant answers using only the accounts and fields that salesperson is authorized to access, and the app never needs broad SQL or workspace-administration capability to do it. The service principal does not disappear: Databricks keeps app authorization for app-owned work such as reading shared configuration or writing application metrics, and the guidance is to keep those two clients separate inside the app.
Two limits, and they are not the same limit #
The source is precise about which control does what. API scopes limit the operations the app can perform on the user's behalf. The user's warehouse and Unity Catalog permissions limit which data it can reach. Scope down to the narrowest scope that matches the job, configure it explicitly on the app, and let workspace administrators set the upper boundary over the top.
The operational rules are short enough to put in a review checklist. Use the forwarded token only for the active request. Fail closed when the token is missing. Never store user tokens. That last one is the rule teams break first, usually because someone wants a background job to run as the person who scheduled it.
What this changes for agents #
Databricks says the same pattern applies to agents, which matters more than the apps story on its own. An agent that queries governed tables on a user's behalf has exactly the problem an app has, with the added difficulty that its query is generated rather than written. Telling a model what not to reveal is not a control. Running its queries under the asker's identity is. The Databricks Apps and Agents chapters both assume that boundary, and this release makes it the supported default rather than something you argue for.
Questions people ask #
What is on-behalf-of-user authorization in Databricks Apps? #
It lets a Databricks App call supported Databricks APIs using the identity of the signed-in user, so Unity Catalog enforces that user's data permissions, including row filters and column masks. API scopes separately limit which operations the app can perform on the user's behalf.
Is on-behalf-of-user authorization generally available? #
Yes. Databricks announced general availability on 7 October 2026.
Can a Databricks App still use its own service principal? #
Yes. Apps keep a dedicated service principal for app-owned operations such as reading shared configuration or writing application metrics, and Databricks recommends keeping the app client and the user client separate.