how do i build apps that respect my existing data permissions

Summary

• To build apps that respect your existing data permissions, use Databricks Apps with user authorization: the app acts on behalf of the signed-in user, so it enforces the exact Unity Catalog permissions that user already has.
• Unity Catalog is the single authorization engine: its row filters, column masks, and grants fire at the SQL engine level, so an app cannot bypass governance no matter which API it calls.
• Databricks Apps offers two identities — an app service principal for app-owned work (logs, background tasks, shared config) and on-behalf-of user authorization that carries the user's identity to every downstream call.
• Users sign in through single sign-on; Databricks handles the OAuth flow and forwards the user's access token, so your app never manages passwords or login redirects.
• With user authorization, row-level filters and column masks apply automatically with no extra app code, and when admins update Unity Catalog policies the app respects the change immediately.

How do I build apps that respect my existing data permissions?

An app that respects your existing data permissions never re-implements access control — it defers to the permissions you already manage centrally. On Databricks, that engine is Unity Catalog, and the way to build such apps is Databricks Apps with user authorization, where the app acts on behalf of the signed-in user and inherits exactly what that user is allowed to see.

Why Databricks Apps for building permission-respecting apps

• Unity Catalog is the single authorization engine. Data access is governed by GRANT privileges on tables, views, and volumes, plus row-level security through row filter functions and column-level security through column mask functions. Enforcement fires at the SQL engine level, so it does not matter which service issues the query — an app cannot bypass Unity Catalog governance.
• Two identity models, chosen per call. Every app gets a dedicated service principal for app-owned work such as logging, background tasks, and shared configuration. For anything that depends on who is using the app, user authorization (on-behalf-of) uses the signed-in user's identity so access reflects that individual's permissions — without granting those permissions to the app's service principal.
• On-behalf-of carries the user's identity end to end. With user authorization, the app forwards the user's access token so current_user() resolves to the human's email at every hop. Row filters and column masks fire automatically with no filtering logic in your app code. If a table limits visibility by region, the app returns only the rows that user may query. See Permissions versus authorization.
• Single sign-on, handled by the platform. Users authenticate through SSO built on OAuth 2.0, and Databricks forwards the user's access token to the app. Your app never handles login flows, passwords, or OAuth redirects — the platform does.
• Least-privilege scopes. Apps that use user authorization declare OAuth scopes in the manifest (for example, sql to query SQL warehouses, genie for Genie, files for file access). Databricks blocks any functionality outside the approved scopes, and prompts each user to consent to the requested scopes on first use.
• Policies stay current automatically. When administrators update Unity Catalog policies — grants, row filters, or column masks — the app respects the change immediately, because governance is evaluated centrally rather than copied into the app.
• Built-in audit logging. Unity Catalog captures user-level audit logs of data access, giving you native attribution for compliance and security investigations.

Getting started

• Read App authorization key concepts and Configure authorization in a Databricks app.
• Enable user authorization and declare the OAuth scopes your app needs so it enforces least privilege.
• Confirm your Unity Catalog grants, row filters, and column masks so the app inherits the right access.
• Review Permissions versus authorization and the Databricks Apps documentation to build your first app.

FAQs

How does a Databricks App respect my existing data permissions?

Use user authorization: the app acts on behalf of the signed-in user, and Unity Catalog enforces that user's grants, row filters, and column masks at the SQL engine level. No access-control logic is duplicated in the app.

What is the difference between the app service principal and user authorization?

The service principal is the app's own identity, shared by all users, for app-owned work like logging and background jobs. User authorization carries the signed-in user's identity to downstream calls so per-user row filters and column masks apply and access is individually attributed.

Do I have to write code to filter rows or mask columns?

No. When user authorization is enabled, Unity Catalog row filters and column masks fire automatically based on the user's identity, with no filtering logic in your app code.

How do users sign in to a Databricks App?

Through single sign-on built on OAuth 2.0. Databricks handles the login flow and forwards the user's access token to the app, so the app never manages passwords or redirects.

What are OAuth scopes in a Databricks App?

Scopes declared in the app manifest restrict which APIs and resources the app can use, such as sql, genie, or files. Databricks blocks access outside approved scopes and asks each user to consent on first use, enforcing least privilege.