OIDC SSO Configuration Errors After Modifying Advanced Settings in DataHub Cloud – DataHub Customer Support Portal

```html

Area: Deployment Issues

Sub-Area: OIDC SSO Configuration

Issue

In DataHub Cloud, clearing or deleting values from the OIDC Advanced Settings fields (such as User Name Claim, User Name Claim Regex, and Scope) via the Settings UI does not restore those fields to their backend defaults. Instead, the fields are saved as empty strings, which override the intended defaults and cause SSO login to fail entirely. A secondary failure can occur if the OIDC redirect URI used during the authentication flow does not match the URI registered in the identity provider (e.g., Okta), resulting in a redirect URI mismatch error that prevents users from completing login.

Error Messages

Failed to redirect to Single Sign-On provider. Please contact your DataHub Administrator, or refer to server logs for more information.
Error: The 'redirect_uri' parameter must be a Login redirect URI in the client app settings

You Might Be Asking

Why did clearing the OIDC Advanced Settings fields break SSO instead of restoring the defaults?
What are the correct default values for User Name Claim, User Name Claim Regex, and Scope?
Why is the redirect URI sent to my identity provider different from the one I registered?
How do I restore SSO access after accidentally clearing OIDC advanced settings in DataHub Cloud?

Solution

Understand the root cause — empty strings vs. missing values.
When OIDC Advanced Settings fields are cleared in the DataHub Cloud UI, the fields are persisted as empty strings ("") rather than being removed from the configuration. DataHub's OIDC configuration logic applies backend defaults only when a field is null or absent — an explicit empty string is treated as a valid (but broken) value and overrides the default. This causes the OIDC callback to fail because it attempts to resolve an empty claim name against the identity provider's token response.
Restore the recommended default values for OIDC Advanced Settings.
In DataHub Cloud, backend configuration changes are managed by DataHub Support. Contact support and request that the following values be explicitly set for your environment:
```
User Name Claim:       email
User Name Claim Regex: ([^@]+)
Scope:                 openid profile email groups
```
These values align with the backend defaults defined in OidcConfigs.java and represent the recommended starting configuration for most OIDC providers.

If you have self-managed access to the Helm values for the datahub-frontend deployment, you can set these under the OIDC configuration block:
```
datahub-frontend:
  oidc:
    userNameClaim: "email"
    userNameClaimRegex: "([^@]+)"
    scope: "openid profile email groups"
```
After applying the values, restart the datahub-frontend pod.
Verify the OIDC redirect URI registered in your identity provider.
After restoring the OIDC settings, confirm that the redirect URI used by DataHub matches the URI registered in your identity provider's application settings. The correct redirect URI format for DataHub Cloud is:
```
https://<your-instance>.acryl.io/callback/oidc
```
Ensure this exact URI (with no trailing slashes, hidden Unicode characters, or internal hostnames) is listed as a permitted Sign-in Redirect URI in your OIDC provider's application configuration (e.g., in Okta under the app's General tab).
Identify and correct internal hostname redirect URI mismatches.
A known behavior in DataHub Cloud is that the OIDC redirect URI can be auto-populated with an internal infrastructure hostname (e.g., https://<your-instance>.use1-saas-01-prod.acryl.io/callback/oidc) rather than the public-facing URL. This occurs because the redirect URI is sometimes derived from the host observed by the frontend service rather than the configured public domain.

If you observe that the authorization request sent to your identity provider contains an unexpected internal hostname in the redirect_uri parameter, confirm the following with DataHub Support:
- The correct public-facing redirect URI is explicitly configured in the deployment.
- Any internal hostnames visible in the auth flow are not being propagated to the OIDC client.
You can inspect the actual redirect URI being sent to your provider by examining the full authorization URL in your browser's address bar or network traffic during the login flow. It will appear as the value of the redirect_uri query parameter, for example:
```
https://<your-idp>/oauth2/v1/authorize
  ?scope=openid%20profile%20email%20groups
  &response_type=code
  &redirect_uri=https%3A%2F%2F<your-instance>.acryl.io%2Fcallback%2Foidc
  &client_id=<your-client-id>
  ...
```
Decode the redirect_uri value and compare it to the URI registered in your identity provider. They must match exactly.
Re-register the redirect URI in your identity provider if needed.
If the redirect URI has changed (e.g., from a public hostname to an internal hostname or vice versa), update your OIDC application in the identity provider to include the correct URI. For Okta, navigate to: Admin Console → Applications → [Your App] → General → Sign-in redirect URIs and add or correct the entry:
```
https://<your-instance>.acryl.io/callback/oidc
```
Validate SSO login after all changes.
After restoring the OIDC advanced settings and verifying the redirect URI, attempt to log in via SSO. Note that configuration propagation in DataHub Cloud may take a short time. If the error persists immediately after a fix is applied, wait a few minutes and retry before escalating further.

Additional Notes

DataHub Cloud (Managed Service): In DataHub Cloud environments, OIDC backend configuration is managed by DataHub Support. Customers do not have direct access to the Helm values or pod configuration. If you are locked out of SSO, contact DataHub Support immediately and provide your desired OIDC advanced settings values so they can be applied on your behalf.

Known behavior — empty strings vs. defaults: This is a known behavioral inconsistency in the OIDC configuration logic. Clearing a field in the Advanced Settings UI saves an empty string rather than removing the key, which bypasses backend default resolution. This affects the User Name Claim, User Name Claim Regex, and Scope fields. Avoid clearing these fields without immediately supplying explicit replacement values.

Frontend vs. backend default mismatch: The frontend UI may display preferred_username as the default for User Name Claim, while the backend default is email. If your identity provider does not return a preferred_username claim, explicitly set the User Name Claim to email or another claim your IdP does return.

Self-managed deployments: If you manage your own DataHub deployment via Helm, you can apply the OIDC configuration values directly to your datahub-frontend Helm values file and perform a rolling restart of the frontend pod to apply the changes.

Issue

Error Messages

You Might Be Asking

Solution

Additional Notes

Related Documentation