Authentication¶
Web applications have a different authentication (authN) and authorization (authZ) model from Notebooks or Dashboards. This is one of the main sources of confusing for Databricks users that are not yet used to application development.
OIDC/OAuth¶
Apps use OIDC/OAuth2 for authenticating and authorizing with Databricks.
App developers do not need to know how to implement the OAuth authorization flow. It is all taken care by our platform. Every app gets its own custom OAuth app integration and service principal.
- The service principal for the app will be created with the name
app(m2m) <appname>. - The custom Oauth application will be created with the name
app-<appname>.
On behalf of the application¶
Every App is assigned its own service principal, with access only to the workspace where the app is installed.
The service principal client and secret is inject as an environment variable in all apps. These environment variables are standard in Databricks.
| Variable | Value |
|---|---|
| DATABRICKS_CLIENT_ID | service principal OAuth client id |
| DATABRICKS_CLIENT_SECRET | service principal OAuth client secret |
On behalf of the user (future)¶
Every App is integrated with Databricks OIDC/OAuth2 and SSO. We do not support any other form of authentication such as Personal Access Tokens.
There are several benefits to securing the application this way:
- Administrators can control the authorization scope the OAuth application can request.
- Tokens are short-lived. The actual app is only given the access token, not the refresh token.
The user's info and access token (future) are forwarded to the application using headers. Application developers can access them using normal HTTP request features.
| Header | Description |
|---|---|
X-Forwarded-User |
User ID |
X-Forwarded-Email |
User email |
X-Forwarded-Preferred-Username |
User name |
X-Forwarded-Access-Token |
User access token (future) |
More resources¶
Databricks clients: Learn how to use the Databricks clients in your app