Skip to main content

Troubleshooting SSO OIDC Integration Failures with Microsoft Entra (Azure AD)

Angelo Bresci
Updated

Area: Deployment Issues

Sub-Area: SSO / OIDC Authentication Configuration

Issue

When configuring OpenID Connect (OIDC) Single Sign-On with Microsoft Entra (formerly Azure AD) in DataHub, users may encounter silent or generic authentication failures. The identity provider (Entra) may report a successful sign-in event, while DataHub presents a generic "Failed to sign in using Single Sign-On provider" error with no additional detail visible in the UI. This is commonly caused by a combination of stale or incorrectly copied client credentials, missing optional claims in the ID token, incorrect userNameClaim configuration, or missing admin consent on the Entra app registration.

Error Messages

  • TechnicalException: Bad token response, error=invalid_client
  • AADSTS65004: User declined to consent to access the app

You Might Be Asking

  • Why does Entra show a successful login but DataHub still fails to authenticate the user?
  • What does invalid_client mean in the context of DataHub OIDC SSO?
  • What value should I use for userNameClaim when integrating DataHub with Microsoft Entra?
  • Why is the email claim missing from my Entra ID token?
  • How do I grant admin consent for the DataHub app in Entra?

Solution

Work through the following diagnostic steps in order. The most frequent root causes are an invalid client secret and a misconfigured userNameClaim.

  1. Regenerate and re-enter the Client Secret.

    The invalid_client error most commonly indicates that the client secret stored in DataHub is stale, expired, or was copied incorrectly. The Azure portal displays two columns that look similar — the secret Value and the secret ID (a GUID). DataHub requires the Value.

    1. In the Azure portal, navigate to App Registrations → [Your DataHub App] → Certificates & secrets.
    2. Generate a new client secret and immediately copy the Value column (the long credential string, not the Secret ID GUID).
    3. In DataHub, navigate to Settings → Platform → SSO → OIDC and paste the new value into the Client Secret field.
  2. Verify the Client ID.

    Confirm that the Application (client) ID shown in the Azure App Registration overview matches exactly what is entered in DataHub's OIDC settings.

  3. Grant admin consent for API permissions.

    The AADSTS65004 error indicates that admin consent has not been granted, or that an individual user declined the consent prompt. Granting tenant-wide admin consent eliminates per-user consent prompts.

    1. In the Azure portal, navigate to App Registrations → [Your DataHub App] → API Permissions.
    2. Ensure the following permissions are present: openid, profile, email, User.Read.
    3. Click "Grant admin consent for [your tenant]" and confirm.
  4. Add the email optional claim to the ID token.

    Microsoft Entra does not include the email claim in the ID token by default, even when the email permission is granted. DataHub's default userNameClaim is email, so if this claim is absent the authentication callback will fail.

    1. In the Azure portal, navigate to App Registrations → [Your DataHub App] → Token configuration.
    2. Click Add optional claim → ID token, select email, and save.
    3. Verify that the user's Entra profile has an email address populated. Accounts synchronized from on-premises Active Directory may have a null email field.
  5. Set a valid userNameClaim.

    The userNameClaim field in DataHub must contain a claim name that is actually present in the ID token returned by Entra. Setting it to a value such as openid (which is a scope, not a claim) will cause silent failures.

    To identify valid claim names for your Entra tenant, open your OIDC Discovery URI in a browser and inspect the claims_supported array:

    https://login.microsoftonline.com/<your-tenant-id>/v2.0/.well-known/openid-configuration

    Common valid values for userNameClaim with Entra include:

    • email — recommended; requires the optional claim to be explicitly added (see Step 4)
    • preferred_username — usually present by default; contains the UPN
    • upn — available when profile scope is granted

    In DataHub Cloud, update this value under Settings → Platform → SSO → OIDC → User Name Claim.

  6. Verify the Redirect URI is an exact match.

    The redirect URI registered in the Azure app registration must exactly match the DataHub callback URL, including scheme, hostname, and path. Any difference — trailing slash, HTTP vs HTTPS, or case variation — will cause a silent failure.

    https://<your-instance>.datahubproject.io/callback/oidc

    In the Azure portal, confirm this value is listed under App Registrations → [Your DataHub App] → Authentication → Redirect URIs.

  7. Confirm OIDC scope configuration.

    The OIDC scope setting in DataHub should include all three of the following values:

    openid profile email
  8. Confirm the Discovery URI is publicly accessible.

    DataHub must be able to reach the Entra Discovery URI at runtime. If your Entra tenant is configured to restrict access via VPN or conditional access policies, DataHub Cloud will be unable to fetch the OpenID configuration document, causing the OIDC flow to fail.

    https://login.microsoftonline.com/<your-tenant-id>/v2.0/.well-known/openid-configuration
  9. Check user provisioning requirements.

    If Just-in-Time (JIT) user provisioning is disabled on your DataHub instance, users must be pre-provisioned in DataHub before SSO can succeed — even if Entra authenticates them correctly. Confirm with your DataHub administrator whether JIT provisioning is enabled.

Additional Notes

The UI error "Failed to sign in using Single Sign-On provider" is a generic catch-all message. The specific underlying error (e.g., invalid_client, AADSTS65004) is only visible in DataHub backend logs (datahub-frontend pod, SsoCallbackController / OidcCallbackLogic entries). For DataHub Cloud deployments, these logs are not directly accessible to end users — contact DataHub Support and request that backend logs be reviewed for a specific failed login timestamp. Providing the exact time of a failed attempt will significantly speed up diagnosis. In most confirmed cases, the root cause has been either a stale or incorrectly copied client secret, or a userNameClaim set to a value not present in the Entra ID token.

Related Documentation

Tags: sso, oidc, azure-ad, microsoft-entra, authentication, invalid_client, userNameClaim, admin-consent, deployment, datahub-cloud