🌐 External App Authentication

External Apps Need Access

Your application runs outside Databricks - maybe a web app, CI/CD pipeline, or automation tool.

It needs to call Databricks APIs: query data, invoke models, access Genie, etc.

Traditional approach: Create a PAT or OAuth secret, embed it in your app, manage rotation...

OAuth Token Federation

Bring Your Own IdP - use tokens from your existing identity provider to access Databricks APIs.

• No Databricks secrets to manage or rotate
• Use your existing IdP (Okta, Entra, GitHub, etc.)
• Short-lived tokens with automatic refresh
• Centralized identity management

Two Federation Options

Databricks supports two types of token federation:

Account-wide Federation: All users in your Databricks account can authenticate using tokens from your corporate IdP.

Workload Identity Federation: Automated workloads (CI/CD, external apps) authenticate as a service principal using tokens from the runtime environment.

Account-wide Token Federation

For users authenticating from external applications.

Configure a federation policy at the account level that specifies:

• Issuer URL - Your IdP's OIDC endpoint
• Audiences - Expected aud claim
• Subject claim - Maps to Databricks username

Workload Identity Federation

For automated workloads - CI/CD pipelines, external services.

Create a federation policy on a service principal that specifies:

• Issuer - The workload runtime (e.g., GitHub Actions)
• Subject - The specific workload identity
• Audiences - Expected recipients

Bring Your Own IdP

Any OIDC-compliant identity provider works:

• Corporate IdPs: Okta, Microsoft Entra, Ping, Auth0
• CI/CD Platforms: GitHub Actions, Azure DevOps, GitLab CI, CircleCI
• Cloud Platforms: AWS IAM, GCP Workload Identity, Kubernetes

If it can issue JWTs with iss, aud, and sub claims, it can federate with Databricks.

The Exchange Flow

Step 1: Your app authenticates with your IdP and receives a JWT.

Step 2: Exchange the JWT at Databricks token endpoint:

POST /oidc/v1/token with:

• grant_type=urn:ietf:params:oauth:grant-type:token-exchange
• subject_token=<your-jwt>
• subject_token_type=urn:ietf:params:oauth:token-type:jwt

Get Databricks Token

Step 3: Databricks validates your JWT against the federation policy and returns a Databricks OAuth token.

Step 4: Use the Databricks token to call APIs:

Authorization: Bearer <databricks-oauth-token>

GitHub Actions Example

Configure a service principal federation policy:

• Issuer: https://token.actions.githubusercontent.com
• Audience: https://github.com/my-org
• Subject: repo:my-org/my-repo:environment:prod

In your workflow, GitHub automatically provides a JWT via ACTIONS_ID_TOKEN_REQUEST_TOKEN.

Native OAuth with Entra

For Azure Databricks, you can use Entra tokens directly - no exchange needed.

• U2M: Authorization Code flow with PKCE via MSAL
• M2M: Client Credentials flow

Request tokens with scope:

• 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d/user_impersonation (U2M)
• 2ff814a6-3304-4ab8-85cb-cd0e6f879c1d/.default (M2M)

Setting Up Federation

Account-wide: Account Console → Settings → Authentication → Federation Policies

Workload Identity: Account Console → User Management → Service Principals → Federation Policies

Or use the CLI:

databricks account federation-policy create

databricks account service-principal-federation-policy create

Key Takeaways

No secrets to manage — your IdP handles identity, Databricks validates it.

Account-wide for users, Workload Identity for automation.

Token exchange — IdP JWT → Databricks OAuth token (RFC 8693).

Azure special case — Native Entra tokens work directly (no exchange).

Server-side only — tokens must be handled on your backend, never in the browser.