Now GA: Building permission-aware Databricks Apps with on-behalf-of-user authorization

Databricks Apps allows developers to build and deploy data and AI applications directly on the Databricks platform, including dashboards, operational tools, and custom AI agents. The newly generally available on-behalf-of-user (OBO) authorization enables apps to act using the signed-in user’s identity when calling supported Databricks APIs. Unity Catalog enforces the user’s existing data permissions, such as row filters and column masks, ensuring governed data access without requiring the app to reimplement these rules. API scopes further restrict the operations the app can perform on the user’s behalf, limiting broad capabilities like SQL or workspace administration.

Apps can continue using a dedicated service principal for app-owned operations, such as reading shared configuration or writing application metrics, while user authorization governs operations where the user’s permissions should apply. For example, a sales-insights assistant can answer questions using only the data a salesperson is authorized to access, without granting the app broad SQL or administrative access. Databricks Apps supports two authorization models: app authorization for app-owned operations and user authorization for operations governed by the user’s permissions.

When designing an app, developers must decide whose permissions should govern each operation. Background work should not depend on a user session, and the initiating user’s permissions determine the action’s evaluation. The app should use an app client for app-owned operations and a user client for governed operations, such as read-only SQL queries. The user’s forwarded access token is passed to the SQL connector, and Databricks evaluates the query using the user’s existing warehouse and Unity Catalog permissions.

Administrators can update Unity Catalog policies, and subsequent app requests reflect those changes without code modifications. The app must request appropriate API scopes, such as sql:restricted-query for read-only SQL queries, and avoid requesting unnecessary scopes like files or model-serving unless the app uses those capabilities. Scopes act as a capability ceiling, not a grant of data access, and the user must still have permission to access the target resource.