---
title: Enable Open ID Connect (OIDC) federation for OpenSharing recipients | Databricks on AWS
source: https://docs.databricks.com/aws/en/delta-sharing/create-recipient-oidc-fed
ingestedAt: "2026-06-18T08:05:18.438Z"
---

This page explains how data providers in Databricks can federate authentication to an identity provider (IdP) to govern access to OpenSharing shares created in Databricks. This authentication flow uses OIDC federation, allowing JSON Web Tokens (JWTs) issued by the recipient's IdP as short-lived OAuth tokens authenticated by Databricks. This [Databricks-to-open sharing](https://docs.databricks.com/aws/en/delta-sharing/share-data-databricks) authentication method is designed for recipients who do not have access to a Unity Catalog\-enabled Databricks workspace.

In OIDC Federation, the recipient's IdP is responsible for issuing JWT tokens and enforcing security policies, such as Multi-Factor Authentication (MFA). Likewise, the lifetime of the JWT token is governed by the recipient's IdP.

Databricks does not generate or manage these tokens. It only federates authentication to the recipient's IdP and validates the JWT against the recipient's configured federation policy. Data providers can also choose to federate authentication to their own IdP when sharing data internally with other users or departments within their organization.

OIDC federation is an alternative to using long-lived Databricks\-issued bearer tokens to connect non-Databricks recipients to providers. It enables fine-grained access control, supports MFA, and reduces security risks by eliminating the need for recipients to manage and secure shared credentials.

For information about using bearer tokens to manage authentication to shares instead, see [Create a recipient object for non-Databricks users using bearer tokens (Databricks-to-Open sharing)](https://docs.databricks.com/aws/en/delta-sharing/create-recipient-token).

## How does OIDC federation work in OpenSharing?[​](#how-does-oidc-federation-work-in-opensharing "Direct link to how-does-oidc-federation-work-in-opensharing")

1.  When the data provider creates the recipient in OpenSharing on Databricks, they configure an OIDC token federation policy that specifies the issuer URL of the recipient IdP, such as Microsoft Entra ID or Okta, and defines the recipient user, group, service principal or OAuth application that should have access to the share.
    
2.  Databricks generates an OIDC profile web portal URL, based on the policy, and the provider shares that URL with the recipient.
    
    The end user copies the endpoint URL or downloads the profile file, depending on their preferred platform, and provides the URL or profile file to the platform on which they will query the shared data. This shared profile file downloaded from Databricks OIDC portal web does not contain any sensitive information.
    
    *   For user-to-machine (U2M) authentication, the recipient inputs the recipient endpoint from the OIDC profile web portal into their U2M application.
    *   For machine-to-machine (M2M) authentication, the recipient application developer downloads the profile file and references it in the recipient client app.
3.  When the recipient attempts to access shared data using their preferred platform, the authentication is federated to their IdP.
    
    Databricks does not generate or manage any tokens or credentials. Instead, the recipient's IdP generates a JWT containing identity claims. The lifetime of this short-lived token is enforced by the recipient's IdP. The OpenSharing service then validates the JWT against the recipient's policy to ensure it matches the expected claims, including issuer, audience, and subject. If the validation is successful, the request is authenticated, and access is granted based on Unity Catalog permissions.
    

## Before you begin[​](#before-you-begin "Direct link to Before you begin")

To create a recipient, you must meet the following requirements:

*   You must have the `CREATE RECIPIENT` privilege for the Unity Catalog metastore where the data you want to share is registered.
*   You must create the recipient using a Databricks workspace that has that Unity Catalog metastore attached.
*   If you use a Databricks notebook to create the recipient, your compute must use Databricks Runtime 11.3 LTS or above and either standard or dedicated access mode (formerly shared and single user access modes).

## Which Identity Provider to Use?[​](#which-identity-provider-to-use "Direct link to Which Identity Provider to Use?")

You can use OIDC federation with either an internal or external identity provider, depending on your sharing scenario:

*   **Internal Identity Provider (Provider-Managed)**
    
    *   This is useful for sharing data within large organizations where different departments do not have direct Databricks access but share the same IdP.
    *   This approach allows the provider to manage access on behalf of the recipient.
    *   Security policies, such as MFA and role-based access control, are enforced by the provider's IdP.
*   **External Identity Provider (Recipient-Managed)**
    
    *   The provider sets up the sharing policy to trust the recipient's IdP.
    *   The recipient organization retains full control over who can access the shared data.
    *   Security policies, such as MFA and role-based access control, are enforced by the recipient's IdP.

### Authentication Scenario U2M or M2M[​](#authentication-scenario-u2m-or-m2m "Direct link to Authentication Scenario U2M or M2M")

Secure Open Sharing with OIDC Token Federation supports both User-to-Machine (U2M) and Machine-to-Machine (M2M) authentication flows, enabling a wide range of secure data-sharing scenarios.

### User-to-Machine (U2M) Authentication[​](#user-to-machine-u2m-authentication "Direct link to User-to-Machine (U2M) Authentication")

A user from the recipient organization authenticates using their IdP. If MFA is configured, it is enforced during login.

Once authenticated, users can access shared data using tools like Power BI or Tableau. The data provider can define access policies that restrict data access to specific users or groups within the recipient organization, ensuring precise control over who can access shared resources. The U2M client application (e.g., Power BI) uses the OAuth Authorization Code Grant flow to obtain access tokens from the IdP.

### Machine-to-Machine (M2M) Authentication[​](#machine-to-machine-m2m-authentication "Direct link to Machine-to-Machine (M2M) Authentication")

M2M is ideal for automated workloads, such as nightly jobs or background services, that require access without user interaction. The recipient organization registers a Service Principal in its IdP. This service identity enables applications or scripts to securely access resources programmatically. No secrets or credentials are exchanged between Databricks, the provider, or the recipient. All secret management remains internal to each organization. M2M clients, such as the Python OpenSharing Client or Spark OpenSharing Client, use the OAuth Client Credentials Grant flow to retrieve access tokens from the IdP.

## Create a recipient that uses an OIDC federation policy[​](#create-a-recipient-that-uses-an-oidc-federation-policy "Direct link to Create a recipient that uses an OIDC federation policy")

### Step 1. Create an Open OIDC Federation Recipient[​](#step-1-create-an-open-oidc-federation-recipient "Direct link to Step 1. Create an Open OIDC Federation Recipient")

To create a recipient that authenticates using OIDC:

1.  In your Databricks workspace, click ![Data icon.](data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgMCAxNiAxNiIgZmlsbD0ibm9uZSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KPHBhdGggZmlsbC1ydWxlPSJldmVub2RkIiBjbGlwLXJ1bGU9ImV2ZW5vZGQiIGQ9Ik04LjY0NTc2IDAuMzY4NDUzQzguNTEwODIgMC4xNDAwOTkgOC4yNjUzIDAgOC4wMDAwNiAwQzcuNzM0ODIgMCA3LjQ4OTMgMC4xNDAwOTkgNy4zNTQzNyAwLjM2ODQ1M0w0LjEwNDM3IDUuODY4NDVDMy45NjczNiA2LjEwMDMgMy45NjUxOCA2LjM4NzgxIDQuMDk4NjUgNi42MjE3MUM0LjIzMjEzIDYuODU1NjEgNC40ODA3NiA3IDQuNzUwMDYgN0gxMS4yNTAxQzExLjUxOTQgNyAxMS43NjggNi44NTU2MSAxMS45MDE1IDYuNjIxNzFDMTIuMDM0OSA2LjM4NzgxIDEyLjAzMjggNi4xMDAzIDExLjg5NTggNS44Njg0NUw4LjY0NTc2IDAuMzY4NDUzWk04LjAwMDA2IDIuMjI0MjZMOS45MzU3MiA1LjVINi4wNjQ0TDguMDAwMDYgMi4yMjQyNloiIGZpbGw9IiM2RjZGNkYiLz4KPHBhdGggZmlsbC1ydWxlPSJldmVub2RkIiBjbGlwLXJ1bGU9ImV2ZW5vZGQiIGQ9Ik04LjUgOS4yNUM4LjUgOC44MzU3OSA4LjgzNTc5IDguNSA5LjI1IDguNUgxNC4yNUMxNC42NjQyIDguNSAxNSA4LjgzNTc5IDE1IDkuMjVWMTQuMjVDMTUgMTQuNjY0MiAxNC42NjQyIDE1IDE0LjI1IDE1SDkuMjVDOC44MzU3OSAxNSA4LjUgMTQuNjY0MiA4LjUgMTQuMjVWOS4yNVpNMTAgMTBWMTMuNUgxMy41VjEwSDEwWiIgZmlsbD0iIzZGNkY2RiIvPgo8cGF0aCBmaWxsLXJ1bGU9ImV2ZW5vZGQiIGNsaXAtcnVsZT0iZXZlbm9kZCIgZD0iTTEgMTEuNzVDMSA5Ljk1NTA3IDIuNDU1MDcgOC41IDQuMjUgOC41QzYuMDQ0OTMgOC41IDcuNSA5Ljk1NTA3IDcuNSAxMS43NUM3LjUgMTMuNTQ0OSA2LjA0NDkzIDE1IDQuMjUgMTVDMi40NTUwNyAxNSAxIDEzLjU0NDkgMSAxMS43NVpNNC4yNSAxMEMzLjI4MzUgMTAgMi41IDEwLjc4MzUgMi41IDExLjc1QzIuNSAxMi43MTY1IDMuMjgzNSAxMy41IDQuMjUgMTMuNUM1LjIxNjUgMTMuNSA2IDEyLjcxNjUgNiAxMS43NUM2IDEwLjc4MzUgNS4yMTY1IDEwIDQuMjUgMTBaIiBmaWxsPSIjNkY2RjZGIi8+Cjwvc3ZnPgo=) **Catalog**.
    
2.  At the top of the **Catalog** pane, click the ![Gear icon.](data:image/svg+xml;base64,[encoded data, 5356 characters]) gear icon and select **OpenSharing**.
    
    Alternatively, in the upper-right corner, click **Share > OpenSharing**.
    
3.  On the **Shared by me** tab, click **New recipient**.
    
4.  Enter the **Recipient name**.
    
5.  For **Recipient type**, select **Open**.
    
6.  Choose OIDC Federation as the Open **Authentication method**.
    
7.  Click **Create**.
    
8.  (Optional) Create custom **Recipient properties**. On the recipient **Details** tab, click **Edit properties > +Add property**. Then add a property name (**Key**) and **Value**. For details, see [Manage recipient properties](https://docs.databricks.com/aws/en/delta-sharing/manage-recipients#properties).
    

### Step 2. Create OIDC Federation Policy[​](#step-2-create-oidc-federation-policy "Direct link to Step 2. Create OIDC Federation Policy")

Before creating the policy, gather the necessary information from the recipient about their IdP, including the users, groups, service principals or OAuth applications that should have access to the share. If you're using your own (internal) IdP for internal sharing, retrieve this information from your own identity system.

You must first request information from the recipient about their IdP and the users, groups, service principals or OAuth applications that should have access to the share. You then provide that information in Databricks when you create the recipient.

1.  On the recipient edit page, under **OIDC federation policies**, click **Add policy**.

![OIDC policy configuration dialog](https://docs.databricks.com/aws/en/assets/images/oidc-policy-8336ef6eb80a6c7032de0f44ecce6b6b.png)

1.  Enter the following:
    
    *   **Policy name**: Human-readable name for the policy.
        
    *   **Issuer URL**: The HTTPS URL of the IdP issuing the JWT token.
        
    *   **Subject claim**: The claim in the JWT that identifies the authenticating identity type. In Microsoft Entra ID, you can configure the following values:
        
        *   **`oid` (Object ID)**: Select if a user is intended to access the data via a U2M application, such as PowerBI.
        *   **`groups`**: Select if a group of users is intended to access the data via a U2M application, such as PowerBI.
        *   **`azp`**: Select if an OAuth application is intended to access the data via a M2M application, such as Python OpenSharing Client or Spark OpenSharing Client.
        
        In some other IdPs, claims such as sub or others may be used. Refer to the IdP documentation to determine the correct claim for your use case.
        
    *   **Subject**: The specific user, group, or application allowed to access the share.
        
    *   **Audiences**: One or more resource identifiers the JWT must match. A token is considered valid if its aud claim matches any of the listed audiences.
        
2.  Click **Save**.
    

If you're unsure about the values to use (issuer, subject claim, subject, audience), refer to the following example. You need to determine the details of the OIDC Federation Policy before creating it.

If you are using an external recipient managed IdP request the following information from the recipient shared using a secure channel. If you are using your internal provider managed IdP, this information is from your own IdP based on the identities that you are sharing with.

#### Example for U2M when IdP is Entra ID:[​](#example-for-u2m-when-idp-is-entra-id "Direct link to Example for U2M when IdP is Entra ID:")

These are example configuration for sharing with a specific user with Object ID `11111111-2222-3333-4444-555555555555` in Entra ID tenant `aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee`

*   Issuer: `https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0`
*   subject claim: `oid` (Object ID)
*   Subject: `11111111-2222-3333-4444-555555555555`
*   Audiences: `64978f70-f6a6-4204-a29e-87d74bfea138` (This is the client ID of the multi-tenant app registered by Databricks in Entra ID)

These are example configuration for sharing with a specific group with Object ID `66666666-2222-3333-4444-555555555555` in Entra ID tenant `aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee`

*   Issuer: `https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0`
*   subject claim: `groups`
*   Subject: `66666666-2222-3333-4444-555555555555`
*   Audiences: `64978f70-f6a6-4204-a29e-87d74bfea138` (This is the client ID of the multi-tenant app registered by Databricks in Entra ID)

note

For U2M applications like Power BI and Tableau, the audience should be the multi-tenant app ID registered by Databricks in Entra ID, which is `64978f70-f6a6-4204-a29e-87d74bfea138`.

For more information about U2M applications and their OIDC Federation policies see [Read data shared using Open ID Connect (OIDC) federation in a U2M flow](https://docs.databricks.com/aws/en/delta-sharing/sharing-over-oidc-u2m).

#### Example for M2M when IdP is Entra ID:[​](#example-for-m2m-when-idp-is-entra-id "Direct link to Example for M2M when IdP is Entra ID:")

For an M2M OAuth application with Application (client) ID `11111111-2222-3333-4444-555555555555` in Entra ID tenant `aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee`:

*   Issuer: `https://login.microsoftonline.com/aaaaaaaa-bbbb-4ccc-dddd-eeeeeeeeeeee/v2.0`
*   Subject claim: `azp`
*   subject: `11111111-2222-3333-4444-555555555555` (This is the Application (client) ID, which is the client ID of the registered OAuth application and can be found in the recipient's Entra ID portal)
*   Audiences: `66666666-2222-3333-4444-555555555555` (This can be any valid audience identifier defined by the recipient, such as the client ID of the registered OAuth application.) For more information about M2M applications and their OIDC Federation policies see [Read data shared using Open ID Connect (OIDC) federation in an M2M flow](https://docs.databricks.com/aws/en/delta-sharing/sharing-over-oidc-m2m).

After you've created the recipient and [created shares](https://docs.databricks.com/aws/en/delta-sharing/create-share), you can grant the recipient access to those shares.

To grant share access to recipients, you can use Catalog Explorer, the Databricks Unity Catalog CLI, or the `GRANT ON SHARE` SQL command in a Databricks notebook or the Databricks SQL query editor.

**Permissions required**: One of the following:

*   Metastore admin.
*   Delegated permissions or ownership on both the share and the recipient objects ((`USE SHARE` + `SET SHARE PERMISSION`) or share owner) AND (`USE RECIPIENT` or recipient owner).

For instructions, see [Manage access to OpenSharing data shares (for providers)](https://docs.databricks.com/aws/en/delta-sharing/grant-access).

If your OIDC recipient is reading shared data assets using an Iceberg REST catalog, share the **Iceberg OIDC profile generation portal** link.

Send the link after creating a recipient that uses an OIDC federation policy:

1.  In your Databricks workspace, click ![Data icon.](data:image/svg+xml;base64,PHN2ZyB3aWR0aD0iMTYiIGhlaWdodD0iMTYiIHZpZXdCb3g9IjAgMCAxNiAxNiIgZmlsbD0ibm9uZSIgeG1sbnM9Imh0dHA6Ly93d3cudzMub3JnLzIwMDAvc3ZnIj4KPHBhdGggZmlsbC1ydWxlPSJldmVub2RkIiBjbGlwLXJ1bGU9ImV2ZW5vZGQiIGQ9Ik04LjY0NTc2IDAuMzY4NDUzQzguNTEwODIgMC4xNDAwOTkgOC4yNjUzIDAgOC4wMDAwNiAwQzcuNzM0ODIgMCA3LjQ4OTMgMC4xNDAwOTkgNy4zNTQzNyAwLjM2ODQ1M0w0LjEwNDM3IDUuODY4NDVDMy45NjczNiA2LjEwMDMgMy45NjUxOCA2LjM4NzgxIDQuMDk4NjUgNi42MjE3MUM0LjIzMjEzIDYuODU1NjEgNC40ODA3NiA3IDQuNzUwMDYgN0gxMS4yNTAxQzExLjUxOTQgNyAxMS43NjggNi44NTU2MSAxMS45MDE1IDYuNjIxNzFDMTIuMDM0OSA2LjM4NzgxIDEyLjAzMjggNi4xMDAzIDExLjg5NTggNS44Njg0NUw4LjY0NTc2IDAuMzY4NDUzWk04LjAwMDA2IDIuMjI0MjZMOS45MzU3MiA1LjVINi4wNjQ0TDguMDAwMDYgMi4yMjQyNloiIGZpbGw9IiM2RjZGNkYiLz4KPHBhdGggZmlsbC1ydWxlPSJldmVub2RkIiBjbGlwLXJ1bGU9ImV2ZW5vZGQiIGQ9Ik04LjUgOS4yNUM4LjUgOC44MzU3OSA4LjgzNTc5IDguNSA5LjI1IDguNUgxNC4yNUMxNC42NjQyIDguNSAxNSA4LjgzNTc5IDE1IDkuMjVWMTQuMjVDMTUgMTQuNjY0MiAxNC42NjQyIDE1IDE0LjI1IDE1SDkuMjVDOC44MzU3OSAxNSA4LjUgMTQuNjY0MiA4LjUgMTQuMjVWOS4yNVpNMTAgMTBWMTMuNUgxMy41VjEwSDEwWiIgZmlsbD0iIzZGNkY2RiIvPgo8cGF0aCBmaWxsLXJ1bGU9ImV2ZW5vZGQiIGNsaXAtcnVsZT0iZXZlbm9kZCIgZD0iTTEgMTEuNzVDMSA5Ljk1NTA3IDIuNDU1MDcgOC41IDQuMjUgOC41QzYuMDQ0OTMgOC41IDcuNSA5Ljk1NTA3IDcuNSAxMS43NUM3LjUgMTMuNTQ0OSA2LjA0NDkzIDE1IDQuMjUgMTVDMi40NTUwNyAxNSAxIDEzLjU0NDkgMSAxMS43NVpNNC4yNSAxMEMzLjI4MzUgMTAgMi41IDEwLjc4MzUgMi41IDExLjc1QzIuNSAxMi43MTY1IDMuMjgzNSAxMy41IDQuMjUgMTMuNUM1LjIxNjUgMTMuNSA2IDEyLjcxNjUgNiAxMS43NUM2IDEwLjc4MzUgNS4yMTY1IDEwIDQuMjUgMTBaIiBmaWxsPSIjNkY2RjZGIi8+Cjwvc3ZnPgo=) **Catalog**.
    
2.  At the top of the **Catalog** pane, click the ![Gear icon.](data:image/svg+xml;base64,[encoded data, 5356 characters]) gear icon and select **OpenSharing**.
    
    Alternatively, in the upper-right corner, click **Share > OpenSharing**.
    
3.  On the **Shared by me** tab, click **Recipients**.
    
4.  Find and select the OIDC recipient.
    
5.  On the right side of the page, under **OIDC federation policies**, click **Default OIDC policy**.
    
6.  Copy the **Iceberg OIDC profile generation portal** link and share it with your recipient using a secure method.
    
7.  The link also includes the names of the shares, which the recipient needs to read shared data.
    

## Recipient workflow[​](#recipient-workflow "Direct link to Recipient workflow")

To learn about how recipients authenticate and access shares using OIDC token federation, see:

*   [Read data shared using Open ID Connect (OIDC) federation in a U2M flow](https://docs.databricks.com/aws/en/delta-sharing/sharing-over-oidc-u2m)
*   [Read data shared using Open ID Connect (OIDC) federation in an M2M flow](https://docs.databricks.com/aws/en/delta-sharing/sharing-over-oidc-m2m)
