Build1 publisherNot yet confirmed elsewhere2 min readPublished
Databricks Apps can now query Unity Catalog data as the signed-in user
Databricks made on-behalf-of-user authorization generally available in Databricks Apps, so queries run under the signed-in user's Unity Catalog permissions. Row filters and column masks apply without app code, so the builder's remaining job is choosing which identity each request carries.
The Engineer · Build desk
What happened
- Databricks forwards each signed-in user's access token in the x-forwarded-access-token HTTP header, and the app passes it to the SQL connector on requests that need user context.
- Apps keep their dedicated service principal for app-owned work, such as reading shared configuration or writing application metrics.
- For a read-only assistant, Databricks says to request sql:restricted-query, a scope limited to read-only SQL queries, instead of the broader sql scope.
- The first time a user opens a user-authorized app, Databricks prompts them to consent to the API scopes the app requests.
Compiled by The EngineerSomething wrong?How this is made
Why it matters
- decision Code review for these apps has to check which credential each handler forwards, because a request sent as the service principal returns the app's view to every user.
- exposure An app holding the full sql scope can use each signed-in user's identity as a broad SQL operating credential, so the declared scope sets how far the app can act in every user's name.
- capability Administrators can change who sees which rows without shipping an app release, because Unity Catalog policy updates apply to the app's next requests.
Databricks frames the design question in a single line: "Whose permissions should govern this particular operation?" [17] The answer is set per request path. Databricks expects most production apps to use both identities [4]. Unity Catalog checks whichever identity comes with the call [2][4]. A handler that passes the forwarded user token gets that user's rows and masked columns [2][5]. A handler that uses the service principal gets the app's own view. Databricks recommends that path for app-owned operations and for results that should be identical for every user [4].
The worked example is a sales-insights assistant. A regional manager sees only the accounts in their region, while a national leader sees all regions [14]. None of those rules are in the app's code. The app also gets no broad SQL or workspace-administration rights to answer either of them [14]. Databricks' sample uses Flask and the Databricks SQL Connector for Python to make the token flow explicit. The post says apps built with Databricks AppKit should apply the same principle [15]. I think the explicit version is the one to copy, because it shows the per-request token at the point where the query runs [15].
Scopes are a separate check. "Scopes are a capability ceiling, not a grant of data access," Databricks wrote in the post [9]. A user-context query runs only if the app declared the scope, the user is allowed to use the SQL warehouse, and the user holds the Unity Catalog privileges on the data [10]. The scopes are declared in the app's user-authorization configuration, either in the Databricks UI or in a Declarative Automation Bundle [11][16]. An app that calls Genie or Unity Gateway should ask for genie or ai-gateway. It should not request files, model-serving or vector-search unless it uses them [13]. Each extra scope adds a line to the consent prompt and widens what the app can do on the user's behalf, with no feature behind it [12][18].
For internal analytics over governed tables, I think this is the right split. The row and column rules stay in Unity Catalog, where administrators already maintain them, and the app never holds a copy [2][6][14]. What is left for the app is routing. The user token goes with user questions, and the service principal handles shared configuration and metrics [3][5].
What to watch
- Which further Databricks APIs gain OBO support, since only calls to supported APIs run under the signed-in user's identity.
- How Databricks AppKit exposes the user-context path, given the post tells AppKit builders to follow the same principle as the explicit Flask sample.
- Whether workspace administrators get controls over which scopes an app may declare, since the scope list currently comes from the app's own user-authorization configuration.