Databricks now supports on-behalf-of-user (OBO) authorization, enabling apps to operate under individual user permissions for more secure, governance-aligned data access without duplicating policy logic in app code.
- OBO authorization enforces user permissions in-app without code duplication
- Supports dual authorization: user identity for governed ops, app principal for app-owned ops
- API scopes limit app capabilities, aligning access tightly with need-to-use functions
Infrastructure signal
The introduction of on-behalf-of-user authorization in Databricks marks a significant advancement in cloud infrastructure security and data governance. By leveraging existing user identities and their permissions within Unity Catalog, applications running on Databricks can now execute queries and access data exactly as permitted per user policies, including enforced row-level filters and column masking. This eliminates redundant data-access checks within apps and reduces risks associated with broad privilege delegation.
From a platform perspective, this model separates user-authorized operations from app-owned workflows through distinct identities and API scopes. It enables granular control over API permissions, thereby limiting risk exposure and improving compliance postures. The approach also simplifies developer infrastructure by embedding permission-awareness directly into core API interactions rather than relying on custom authorization layers, which can introduce inconsistency and cost inefficiency.
Developer impact
Developers gain a streamlined workflow for building secure, permission-aware applications by utilizing OBO authorization. This model allows apps to selectively execute operations under the signed-in user’s identity, ensuring that results and data visibility adhere strictly to user permissions without manual policy implementations in application logic. It improves developer productivity by removing the burden of replicating complex governance rules and handling user session permutations for background processing.
The dual approach also clarifies when to use app service principals versus user identities: dedicated service principals can handle consistent, app-owned tasks such as managing configuration and telemetry, while user identity tokens govern access to personalized data queries. The introduction of fine-grained API scopes encourages the principle of least privilege, requiring developers to explicitly request only necessary capabilities—helping enforce tighter security and reducing potential attack surfaces in multi-tenant environments.
What teams should watch
Cloud and data engineering teams should prioritize adoption of OBO authorization to align applications with evolving data governance mandates and simplify compliance audits. Teams responsible for security and access controls will find the separation of app and user permissions useful for tightening overall security posture while maintaining developer agility. Observability teams should ensure monitoring systems distinguish between app-owned and user-authorized operations to effectively track permission usage and detect anomalies.
Product and API design teams need to carefully consider which operations should run under the user’s identity, especially read-only versus administrative tasks, and define minimal API scopes accordingly. Failing to limit scopes tightly could expose broader user permissions than necessary. Additionally, database and analytics platform teams should validate that existing Unity Catalog policies are comprehensive and tested, as app queries will now rely directly on these policies for enforcement, increasing the importance of policy correctness and performance.