---
title: Connect to Azure
description: The Microsoft Azure identity bridge uses OpenID Connect and OAuth to connect to your Azure provider (OP) to authenticate your users and access user information. In OpenID terms, PingOne for Enterprise is the Relying Party (RP) that sends authentication and information requests to the Azure provider.
component: pingoneforenterprise
page_id: pingoneforenterprise:pingone_for_enterprise:p14e_connect_azure
canonical_url: https://docs.pingidentity.com/pingoneforenterprise/pingone_for_enterprise/p14e_connect_azure.html
revdate: June 5, 2024
section_ids:
  about-this-task: About this task
  steps: Steps
  result: Result:
  result-2: Result
---

# Connect to Azure

## About this task

The Microsoft Azure identity bridge uses OpenID Connect and OAuth to connect to your Azure provider (OP) to authenticate your users and access user information. In OpenID terms, PingOne for Enterprise is the Relying Party (RP) that sends authentication and information requests to the Azure provider.

To configure the identity bridge, you'll be working on both the Azure and PingOne for Enterprise sides and copying information from your Azure tenant to the PingOne for Enterprise identity bridge setup.

OpenID Connect supports a discovery mechanism whereby an OpenID Connect host publishes metadata using a well-known URL, by convention of the form: `https://host.com/.well-known/openid-configuration`. The URL returns OpenID Connect and OAuth endpoints, supported scopes and claims, public keys used to sign tokens, and other metadata. We use this metadata to complete your authentication requests and requests for user information.

## Steps

1. In PingOne for Enterprise, go to **Setup > Identity Repository**, click **Connect to an Identity Repository**, and select **Microsoft Azure AD**. Click **Next**.

2. Sign on to your Azure tenant and go to **Azure Active Directory > Add > App registration**.

   1. On the **Register an application** page, enter a name for the PingOne for Enterprise client (such as, "PingOne").

   2. Under **Supported Account Types**, click to select which Microsoft account types you will allow access.

   3. **Optional:** Under **Redirect URI**, select an authentication method from the list, and in the text field enter a URL.

   4. Click **Register** to save the PingOne for Enterprise client.

      ### Result:

      The application overview page is displayed.

3. Copy the **Application (client) ID** value.

4. PingOne for Enterprise, on the **Configure Your Microsoft Azure Connection** tab, paste the **Application (client) ID** value into the **Client ID** field.

5. In Azure, click **Add a certificate or secret** and click **New client secret**.

   1. Enter a description and expiration for the client secret.

   You'll need to update the client secret when it expires.

   1. Click **Add** to add the new client secret.

   2. Copy the **Value** value.

6. In PingOne for Enterprise, paste the Client ID value into the **Client Secret** field.

7. In Azure, return to the overview page.

   1. Click **Endpoints** to display the OAuth endpoints for your Azure tenant.

   2. Copy the URL for the **OpenID Connect metadata document** endpoint.

8. In PingOne for Enterprise, while still on the **Configure Your Microsoft Azure Connection** panel, for **Discovery Endpoint**, enter the URL for the OpenID Connect metadata document endpoint you copied from your Azure tenant.

9. Click **Verify**.

   PingOne for Enterprise will verify that it can query the endpoint or endpoints you've specified. If verification isn't successful, check that the endpoint or endpoints appear exactly as they do on your OpenID Connect provider.

10. For **Scope**, select the OAuth scopes that you'd like us to include in authentication requests, then click **Next**.

    The available scopes of authorization for your Azure tenant are displayed based on the response from your supplied **Discovery Endpoint**. The scopes indicate the access privileges you're requesting for the access token returned by Azure. We use the access token to request additional claims from the userinfo endpoint.

11. In Azure, close the **Endpoints** panel and from the *clientName* IdP (Test) page, click **API permissions** for your PingOne for Enterprise client.

    1. Check whether **User.Read** is already added by default.

    If it isn't already added, you'll add it in a subsequent step.

    1. Click **Add a permission**.

    2. The Request API permissions page is displayed. Select **Microsoft APIs > Microsoft Graph**.

    3. For **What type of permissions does your application require?**, select **Application permissions**.

    4. The list of APIs is displayed. Expand **Group** and select **Group.Read.All**.

    5. If the **User.Read** permission wasn't added by default, expand **User** and select **User.Read**.

    6. On the API permissions page, click **Add permissions**.

    7. Click **Grant admin consent for…​**.

       Doing this ensures your users don't need to grant consent during SSO.

12. On the *clientName* IdP (Test) page, click **Manifest**.

13. Find the **groupMembershipClaims** element and change it from "null" to either "SecurityGroup" or "All".

    This will ensure that the group membership claim is sent in the access token to PingOne for Enterprise during SSO.

14. In PingOne for Enterprise, on the **Microsoft Azure Provider** panel, copy the displayed **PingOne Redirect URI**.

    The PingOne Redirect URI is the URI assigned by PingOne to which your Azure tenant sends OAuth authorization codes indicating whether or not a user was authenticated.

    To ensure security, the PingOne for Enterprise redirect URI includes a verification code unique to your account. The redirect URI used by your Azure tenant for the PingOne client must include the verification code for SSO to be successful.

15. In Azure, go to the **Overview** page for your registered PingOne for Enterprise client and click the link for **Redirect URIs**.

    1. Add a new Redirect URI of type **Web**.

    2. Enter the URI you copied from the **Microsoft Azure Provider** panel in PingOne for Enterprise.

    3. Click **Save**.

16. In PingOne for Enterprise, assign the Azure provider-to-PingOne for Enterprise attribute mapping.

    This assignment maps your selected Azure provider attributes to the default PingOne for Enterprise attributes (used by PingOne for Enterprise dock). This attribute mapping is not used by applications that you add to PingOne for Enterprise. You will configure those identity provider-to-service provider attribute mappings for each application.

    |   |                                                                                                                                                                                                                                                                                                                                                                                   |
    | - | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
    |   | If you're also using PingID for Azure Conditional Access, make sure the `MFA_SUBJECT` mapping for PingOne for Enterprise matches the `username` mapping for PingID.Learn more in [Configuring PingID MFA for Microsoft Azure AD Conditional Access](https://docs.pingidentity.com//pingid/pingid_integrations/pid_cfg_azure_conditional_access.html) in the PingID documentation. |

    1. For any of the attribute mappings, you can choose to configure an advanced mapping. Find instructions in [Creating advanced attribute mappings](p14e_creating_advaced_attribute_mappings.html).

    2. Click **Next** when you're finished.

17. Choose whether or not to synchronize the user groups on your Azure provider with your PingOne user groups.

    Group synchronization relies on the Microsoft Graph API permissions you specified for the PingOne client you registered in Azure. The permissions `User.Read` and `Group.Read.All` are required for synchronization to be successful.

    Any PingOne for Enterprise user groups that do not exist in your Azure provider will be replaced by the Azure groups.

    Each of your Azure group members are automatically added to the corresponding PingOne for Enterprise groups when the user initially signs on (SSO) to PingOne for Enterprise This is PingOne for Enterprises just-in-time user provisioning.

    1. When you elect to synchronize your Azure groups with PingOne for Enterprise, a banner is displayed notifying you that synchronization is under way. In the banner is a **User Groups** link. Clicking this link will take you to the User Groups page where you can see the groups being added to PingOne for Enterprise

       The Azure groups are added using their Azure group IDs. After this initial synchronization, when additions or changes to your Azure groups occur, you'll need to choose to resynchronize the groups using the **Synchronize Groups** button on the User Groups page. See [Adding user groups](p14e_add_groups.html) for more information.

    2. Click **Done**.

## Result

Your Azure identity bridge is now set up.
