DatabricksAakrati Talati, Cynthya Peranandam, Tushar Madan, Evan Pandya, Theo FernandezAnnouncement
Databricks Apps now generally supports on-behalf-of-user (OBO) authorization, enabling apps to act using the signed-in user’s identity so Unity Catalog enforces existing data permissions including row filters and column masks. Developers choose between app authorization for app-owned operations and user authorization for user-specific data access, with API scopes such as sql:restricted-query limiting what the app can do on the user’s behalf. The forwarded user access token is short-lived and per-request, passed via the x-forwarded-access-token HTTP header to the SQL connector, and the app must never store it. Workspace administrators can set an allowlist of API scopes, providing two levels of control: the app declares minimum scopes and the workspace defines the maximum, with account administrators able to add scopes outside the allowlist. The post recommends keeping app-owned and user-authorized clients separate in code and failing closed when a user token is missing to avoid returning results with incorrect permissions.
Databricks Apps is a platform for building data and AI applications directly on Databricks. The new on-behalf-of-user authorization allows apps to use the signed-in user’s identity to enforce Unity Catalog permissions, with API scopes limiting operations.
Use on-behalf-of-user authorization by configuring the app with an explicit API scope (e.g., sql:restricted-query), retrieving the forwarded user access token from the x-forwarded-access-token header per request, and passing it to the Databricks SQL connector. Keep app-owned and user-authorized clients separate in code and tests, and fail closed if the user token is missing.
OBO authorization lets apps enforce Unity Catalog permissions (row filters, column masks) without reimplementing governance in application code.
API scopes like sql:restricted-query limit what the app can do on the user’s behalf; workspace administrators can set an allowlist to control maximum scopes.
The forwarded user token is short-lived and per-request; apps must never store it and should fail closed if the token is missing.
App authorization uses the app's dedicated service principal for app-owned operations like reading shared configuration. User authorization uses the signed-in user's identity via OBO, so Unity Catalog enforces that user's data permissions. Most production apps use both models for different request paths.
A read-only analytics app should request sql:restricted-query, which allows executing read-only SQL queries but not broader SQL operations like managing resources. This matches the app's product behavior to its authorization boundary.
Workspace administrators set an allowlist under Settings > Development > Apps, defining the maximum API scopes available to apps. The default is all supported APIs; it can be narrowed to selected scopes or set to None to disable user authorization.
Summaries are generated from the original by a language model. Check the original before relying on it.
See the idea
BIAN gives banks a shared vocabulary and service-domain contracts that sit between business concepts and the systems implementing them. See how domains, contracts, and governed access stack into one architecture.
Keep reading
The Good Stuff
Paid picks we use ourselves. Links carry a referral code — a subscription through one earns us a commission at no extra cost to you.
One useful email. Unsubscribe anytime.
