Generative AI on Databricks<\/a>, that distinction is critical because GenAI apps often combine shared operations\u2014logging, configuration, model access\u2014with user-specific data access. Choosing one identity for every operation can either over-privilege the app or remove the per-user governance the business needs.<\/p>\nDatabricks automatically creates a dedicated service principal for each app instance. That identity remains stable across app deployments and is deleted with the app.<\/p>\n
App authorization is for work the application owns<\/h3>\n The app service principal is appropriate for shared application behavior that does not depend on the current user: writing operational logs, reading shared configuration, calling an external service, or querying a dataset every app user should see identically.<\/p>\n
Permissions should be granted explicitly to the app service principal. The app cannot assume access merely because the developer who created it can query the resource.<\/p>\n
This separation improves auditability because app-owned actions remain attributable to one workload identity.<\/p>\n
User authorization preserves Unity Catalog permissions<\/h3>\n When user authorization is enabled, the app can use the user\u2019s Databricks identity to access supported resources. Unity Catalog row filters and column masks continue to apply because the resource sees the real user rather than one shared app identity.<\/p>\n
This is the preferred pattern when different users are allowed to see different rows, columns, schemas, or other governed assets.<\/p>\n
Application code should avoid duplicating these authorization rules in a second bespoke permission system when Unity Catalog already owns them.<\/p>\n
App and user authorization can be used together<\/h3>\n Many production apps need both models simultaneously. The app service principal can write shared logs or call a model service, while user authorization is used for a SQL query whose result depends on the signed-in user.<\/p>\n
The code should make that identity choice explicit for every outbound operation. A helper client that silently defaults to app credentials can accidentally bypass intended per-user filtering.<\/p>\n
Testing should include two users with different Unity Catalog permissions so the authorization boundary is proven rather than assumed.<\/p>\n
App credentials are injected into the runtime<\/h3>\n Databricks injects OAuth client credentials for the app service principal into the app runtime. The Databricks SDKs can use unified authentication and detect those credentials automatically.<\/p>\n
The application should not print or expose these credentials and should avoid copying them into configuration files.<\/p>\n
Secret-handling policy should treat the runtime environment as sensitive even though the platform provisions the credentials automatically.<\/p>\n
User authorization is scoped to the app\u2019s workspace<\/h3>\n Current Databricks documentation notes that forwarded user tokens are scoped to the workspace where the app runs. An app cannot use that token to query a SQL warehouse or another protected resource in a different workspace.<\/p>\n
If cross-workspace access is required, one option is to deploy the app in the workspace containing the resource. Another is to use a service principal for machine-to-machine access when per-user enforcement is not required.<\/p>\n
This workspace boundary should be part of multi-workspace architecture planning before the app is deployed.<\/p>\n
SSO establishes the user identity before app authorization begins<\/h3>\n Users authenticate to Databricks through the workspace identity layer, typically SSO when configured. OAuth user-to-machine flows are then used so the app can access Databricks resources on behalf of the user.<\/p>\n
The app should trust the Databricks-authenticated identity, not a user ID passed in a query string or model prompt.<\/p>\n
Identity used for authorization must come from the trusted authentication channel.<\/p>\n
M2M OAuth supports workload access outside user context<\/h3>\n Machine-to-machine OAuth is the service-principal path for automated workloads. It is appropriate when an app or background process needs to call Databricks resources without a current user.<\/p>\n
The service principal should have the minimum resource permissions required by the task. Giving the app a broad workspace role merely because it runs unattended creates a large blast radius.<\/p>\n
Model-service access, SQL access, and Unity Catalog data access should be granted independently according to need.<\/p>\n
User authorization improves GenAI grounding safety<\/h3>\n A common GenAI pattern is to retrieve enterprise data before calling the model. If the app performs that retrieval under the user\u2019s identity, Unity Catalog can enforce row- and column-level restrictions before the text ever enters the model context.<\/p>\n
This is stronger than retrieving a broad dataset under an app service principal and asking the model or application prompt to hide rows the user should not see.<\/p>\n
Authorization should happen before retrieval, not after generation.<\/p>\n
Audit records should preserve both workload and user context<\/h3>\n For sensitive workflows, operators may need to know which app initiated an action and which user was interacting with it. Application logs and downstream telemetry should preserve both identities where the platform exposes them.<\/p>\n
This helps distinguish a user-driven query from a background task and supports incident review without logging tokens or secrets.<\/p>\n
The app identity and user identity serve different audit purposes and should not be collapsed into one label.<\/p>\n
Authentication architecture is correct when the model cannot invent identity<\/h3>\n The model can decide what information it wants or which tool it thinks is useful, but it should never be allowed to choose which user identity or service principal the application uses to authorize that operation.<\/p>\n
Identity comes from OAuth and platform configuration. Authorization comes from Databricks permissions. The generative model remains a consumer of governed data, not the source of authority.<\/p>\n
Authentication should also be designed for non-interactive app actions. Scheduled background tasks, startup initialization, telemetry export, or cache maintenance should not depend on a user session being active. Those operations belong under app authorization or another workload identity with explicit permissions.<\/p>\n
Conversely, user-sensitive data access should avoid silently falling back to the app service principal when a user token is unavailable. A fallback from user authorization to shared app authorization can turn a transient authentication issue into a data-exposure bug.<\/p>\n
Cross-workspace designs should be especially explicit. If an app must read data from several workspaces, the architecture should decide whether to replicate governed data, deploy the app closer to the resource, or use service-principal access to remote resources. The choice affects whether per-user Unity Catalog filters can still be enforced.<\/p>\n
Token handling should remain inside supported SDK\/authentication flows. Application logs should never record forwarded user tokens, client secrets, or OAuth refresh material. Debugging should use correlation IDs, principal IDs, scopes, and authorization outcomes rather than secret values.<\/p>\n
App permissions should be tested using negative cases. A user without table permission should be denied when the app uses user authorization; an app service principal without EXECUTE on a model service should fail even if the developer personally has permission. Negative tests prove the identity boundary much more convincingly than one successful admin account.<\/p>\n
Authorization changes should be part of deployment review. Granting the app service principal access to another catalog or SQL warehouse can expand what every user of the app can indirectly reach under app authorization. Treat permission diffs as production security changes, not operational cleanup.<\/p>\n
For GenAI applications, the safest pattern is often mixed identity: app identity for shared platform actions, user identity for governed user-specific retrieval, and downstream service-specific identities for external tools. The model sees the results of those authorized operations but never decides which credential path the application uses.<\/p>\n
Databricks Apps should also separate authentication to Databricks from authentication to third-party services. A user\u2019s Databricks OAuth token is not automatically the correct credential for Salesforce, Slack, or another API. External tool access should use the provider\u2019s own OAuth or service identity flow and preserve the distinction between user delegation and app-owned access.<\/p>\n
Authorization failures should be handled as expected product outcomes. A user denied by Unity Catalog should see an appropriate permission error or alternative path, not a generic \u201cAI failed\u201d message that encourages repeated retries.<\/p>\n
App endpoints themselves may expose HTTP APIs, so client authentication, CORS, request validation, and abuse protection still matter even when the backend Databricks access is strongly governed.<\/p>\n
Environment separation should include separate app identities. Development and production apps should not share one service principal or one broad set of resource grants merely to simplify deployment.<\/p>\n
Deletion and offboarding should remove unused app permissions and third-party credentials as well as the app resource. A deleted UI with a lingering service account or secret can leave an unnecessary access path behind.<\/p>\n
Least privilege should be reviewed per resource type. A Databricks app can need EXECUTE on a model service, SELECT on a table, CAN USE on a SQL warehouse, or permission on another workspace asset; granting one broad admin role to avoid these details creates unnecessary risk.<\/p>\n
Session management should also account for user sign-out and token expiry. Long-lived apps should handle expired forwarded credentials gracefully and ask the user to reauthenticate rather than continue with stale or shared credentials.<\/p>\n
Authentication is complete only when every data, model, and tool call can explain which identity was used and why that identity was appropriate for the operation.<\/p>\n","protected":false},"excerpt":{"rendered":"
Databricks Apps uses OAuth 2.0 and separates two identities that application developers often conflate: the app\u2019s own service principal and the signed-in user. App authorization lets the app act as itself with a dedicated service principal. User authorization lets the app use the interacting user\u2019s Databricks identity so Unity Catalog and other per-user permissions continue […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-19805","post","type-post","status-publish","format-standard","hentry","category-general"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t