Skip to main content

SSO Configuration Issues

This page covers common problems with setting up and managing identity provider (IdP) integrations in Prism, including Google OAuth, Microsoft OAuth, custom OIDC providers, and SAML 2.0 providers.

Identity Provider Not Redirecting​

Problem: After clicking "Sign In" or navigating to the portal URL, you are not redirected to your identity provider. Instead, you see a blank page, an error, or the Prism login form.

Cause: The identity provider is not configured correctly in Prism, or the Authorization URL is invalid.

Solution:

  1. In the Admin Portal, navigate to Identity Providers and verify the configuration:
    • Confirm the Authorization URL is correct and reachable. For custom OIDC providers, verify the Issuer, Authorization URL, Token URL, and UserInfo URL.
    • Confirm the Client ID matches what is configured in your IdP.
  2. Test the Authorization URL by pasting it directly into your browser. You should see the IdP login page.
  3. Ensure the identity provider is enabled (not in a draft or disabled state).
  4. Check that there are no network issues (firewalls, proxies) blocking the connection between Prism and your IdP.

"Invalid Client" Error​

Problem: After redirecting to your identity provider, you see an "invalid_client" or "unauthorized_client" error.

Cause: The Client ID or Client Secret configured in Prism does not match what is registered in the identity provider.

Solution:

  1. In the Admin Portal under Identity Providers, verify the Client ID matches exactly with your IdP configuration. Copy and paste to avoid typos.
  2. Re-enter the Client Secret. Secrets cannot be displayed after saving, so if in doubt, generate a new secret in your IdP and update it in Prism.
  3. For each provider, verify the client registration:
    • Google: Go to the Google Cloud Console > APIs & Services > Credentials and check the OAuth 2.0 Client.
    • Microsoft: Go to Azure Portal > Azure Active Directory > App registrations and check the application.
    • Custom OIDC: Check the client registration in your OIDC provider's admin console.
    • SAML 2.0: SAML has no Client ID and no Client Secret, so this error does not apply. The equivalent failures are an Entity ID mismatch, where the identity provider does not recognise the Identifier Prism advertises, and a signature validation failure against the pinned certificate. See SAML 2.0 Issues.
  4. Ensure the client has not been deleted or disabled in the identity provider.

Users Not Appearing After SSO Login​

Problem: Users can authenticate via SSO, but their accounts do not appear in the Prism Users list, or they see "Access Denied" after login.

Cause: SCIM provisioning is not configured, or the user has not been manually created in Prism. SSO authentication alone does not automatically create user accounts in Prism.

Solution:

  1. If SCIM is not configured: Manually create user accounts in the Admin Portal under Users before those users attempt to log in. Users must exist in Prism before they can be authenticated.
  2. If SCIM is configured: Verify the SCIM integration is working correctly:
    • Go to Preferences > SCIM and confirm the SCIM endpoint URL and bearer token are correctly configured in your IdP.
    • Check that the user exists and is assigned to the correct application or group in your IdP.
    • Trigger a manual SCIM sync from your IdP if available.
    • Review SCIM provisioning logs in your IdP for errors.
  3. After the user is provisioned in Prism, they may need to log out and log back in for the changes to take effect.

Google OAuth Issues​

Problem: Google OAuth login fails with various error messages such as "redirect_uri_mismatch", "access_denied", or "invalid_request".

Cause: The Google Cloud Console OAuth configuration does not match the Prism configuration.

Solution:

"redirect_uri_mismatch" Error​

  1. Go to Google Cloud Console > APIs & Services > Credentials.
  2. Select the OAuth 2.0 Client ID used for Prism.
  3. Under Authorized redirect URIs, add the exact callback URL provided by Prism. This is typically displayed in the Identity Provider configuration page in the Admin Portal.
  4. Ensure the URI matches exactly, including the protocol (https://) and path. Trailing slashes matter.
  5. After saving changes in Google Console, wait a few minutes for the changes to propagate.

"access_denied" Error​

  1. Verify that the Google Workspace admin has not restricted which applications can access user data.
  2. If your organization uses Google Workspace, the OAuth app may need to be marked as "trusted" in the Workspace admin console.
  3. Check that the required OAuth scopes (email, profile, openid) are enabled for the client.

General Google OAuth Checklist​

  • OAuth consent screen is configured and published (not in "Testing" mode with limited users).
  • The correct project is selected in Google Cloud Console.
  • The application type is "Web application".
  • Both Authorized JavaScript origins and Authorized redirect URIs are set correctly.

Microsoft OAuth Issues​

Problem: Microsoft (Azure AD) OAuth login fails with errors such as "AADSTS50011" (reply URL mismatch), "AADSTS700016" (application not found), or consent errors.

Cause: The Azure AD app registration does not match the Prism configuration.

Solution:

"AADSTS50011" - Reply URL Mismatch​

  1. Go to Azure Portal > Azure Active Directory > App registrations.
  2. Select the Prism application.
  3. Under Authentication > Redirect URIs, add the exact callback URL from Prism's Identity Provider configuration page.
  4. Ensure the URI type is "Web" (not "SPA" or "Mobile").
  5. Save the changes and wait a few minutes for propagation.

"AADSTS700016" - Application Not Found​

  1. Verify the Client ID (Application ID) in Prism matches the one shown in Azure AD.
  2. Check that the app registration has not been deleted.
  3. If your organization uses multiple Azure AD tenants, ensure you are looking at the correct tenant.
  1. If users see a consent prompt they cannot approve, an Azure AD administrator may need to grant admin consent for the application.
  2. Go to App registrations > API permissions and click Grant admin consent.
  3. Verify that the required permissions (User.Read, email, profile, openid) are listed.

General Microsoft OAuth Checklist​

  • App registration exists and is not expired.
  • Client secret is not expired. Azure AD client secrets have a maximum lifetime.
  • The "Supported account types" setting matches your requirements (single tenant vs. multi-tenant).
  • Redirect URIs match exactly.

Custom OIDC Issues​

Problem: Login with a custom OIDC provider fails, or user attributes are not mapped correctly.

Cause: The OIDC provider configuration in Prism does not match the provider's actual endpoints, or claims mapping is incorrect.

Solution:

Endpoint URL Errors​

  1. Verify that the OIDC endpoint URLs configured in Prism are correct:
    • Issuer, The OIDC Issuer URL of your identity provider.
    • Authorization URL, The endpoint where users are redirected to authenticate.
    • Token URL, The endpoint used to exchange authorization codes for tokens.
    • UserInfo URL, The endpoint used to retrieve user profile information.
  2. Test the endpoints by opening the Issuer URL in a browser. Many providers serve a discovery document at {issuer}/.well-known/openid-configuration.
  3. Ensure all endpoints are reachable from Prism's servers (no firewall or VPN restrictions).
  4. Use the Validate button on the Custom IdP configuration page to verify the endpoints before saving.

Claims Mapping​

  1. After a successful login, if user attributes (name, email) are not populated correctly, the claims mapping may be incorrect.
  2. Verify that your OIDC provider returns the expected claims:
    • email for the user's email address
    • given_name and family_name for the user's name (or name for the full name)
    • sub for the unique user identifier
  3. Some providers return claims in the ID token, while others require a call to the UserInfo endpoint. Ensure the UserInfo URL is correct and accessible.

General Custom OIDC Checklist​

  • Issuer, Authorization URL, Token URL, and UserInfo URL are correct and reachable.
  • Client ID and Client Secret match your OIDC provider's client registration.
  • Redirect/callback URIs are registered in your OIDC provider.
  • Claims are returned in the expected format.

SAML 2.0 Issues​

Problem: Sign-in through a SAML 2.0 identity provider fails, either at the identity provider or on the way back into Prism.

Cause: SAML failures almost always come down to one of five things: the certificate, the email claim, the principal mapping, the metadata that was imported, or a mismatch between the URLs and identifiers configured on the two sides.

Solution:

Signature Validation Failures​

Symptom: The user authenticates at the identity provider and is returned to Prism, which rejects the assertion with a signature or certificate error. Every user is affected, not just one.

  1. The certificate was rotated at the identity provider. Prism pins the signing certificate in the provider configuration and deliberately does not fetch it at login time, so a rotation at the identity provider does not reach Prism on its own. Edit the provider and re-run the metadata import, or paste the new certificate in by hand. For Microsoft Entra ID, re-import from the same App Federation Metadata Url that was used at setup.
  2. The certificate has expired. Expired certificates are silently ignored rather than reported as expired. One expired certificate alongside a valid one is harmless. But if every pinned certificate has expired, there is nothing left to validate against, and every login fails with a generic validation message that does not mention expiry at all. Check the certificate's expiry date at the identity provider before assuming the configuration is wrong. Entra's application signing certificates last three years and Entra emails the notification addresses at 60, 30, and 7 days.
  3. PEM armor was left in a hand-written configuration. Prism expects the certificate as bare base64. The Admin Portal strips the -----BEGIN CERTIFICATE----- and -----END CERTIFICATE----- lines and all whitespace for you, so pasting a full PEM block into the form is safe. A configuration written directly against the API or through Terraform gets no such treatment: a stored certificate that still carries its armor produces nested certificate headers during validation and surfaces as an HTTP 500 at the ACS endpoint, not as a validation error. Strip the armor before writing the value.
  4. Plan a rotation with both certificates in place. The Signing Certificate field accepts multiple certificates comma-separated, and an assertion signed by any one of them is accepted. Add the new certificate alongside the old one before the identity provider switches over, then remove the old one once the cutover is complete. This is the only way to rotate without a window of failed logins.

The User Signs In at the IdP but Prism Rejects the Login​

Symptom: The identity provider shows a successful sign-in in its own logs, the user is redirected back, and Prism then shows a sign-in error.

There are two causes, and they need different fixes.

  1. No Prism account exists with that email address. This is expected behaviour, not a fault. Prism links a federated login to an existing Prism account and never creates one. Create the account first under Admin Portal > Users, or provision it through SCIM or Google Workspace Sync, using the same email address the identity provider sends. Then have the user sign in again.
  2. The identity provider is not sending the email claim. Prism matches federated logins on email, so an assertion with no email attribute cannot be matched to any account, however many accounts exist. Check that:
    • the Email Attribute Name configured in Prism is exactly the claim name the identity provider actually emits, including its full URI where the provider uses one;
    • the claim is populated for the specific user. In Microsoft Entra ID the emailaddress claim is sourced from user.mail, which is empty for mailbox-less users and for most B2B guests. Populate the mailbox attribute, or source the claim from user.userprincipalname where UPNs are real email addresses;
    • for Okta, that an email attribute statement has been added at all (a stock Okta SAML app sends no attribute statements);
    • for Google Workspace, that Principal Type is SUBJECT with the SAML 1.1 emailAddress NameID format, because Google carries the email in the NameID and sends no email attribute.

Distinguishing the two: if a different user with a known-good Prism account signs in successfully, it is cause 1. If nobody can sign in, it is cause 2.

NameID and Principal Mapping​

Symptom: Logins fail immediately after the assertion arrives, or federated users appear in Prism under opaque GUID-like usernames.

  1. Microsoft Entra ID returns an opaque pairwise identifier by default. Entra publishes no NameID format in its metadata, so the format defaults to persistent and the NameID is a per-application pseudonymous identifier that carries no email address and no username. Using it as the principal produces exactly the GUID-shaped usernames above.
  2. Prism therefore reads email from an attribute claim, never from the NameID for Entra. The provider is configured with Principal Type ATTRIBUTE and a Principal Attribute of the UPN claim, http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name, which is always populated. The email arrives separately through the claim named by Email Attribute Name.
  3. The Principal Attribute must name a claim the identity provider actually sends. If it names a claim that is absent from the assertion, the principal resolves to nothing and the sign-in fails outright rather than degrading. Compare the value in Prism against the claim list in the identity provider, character for character.
  4. Do not change Principal Type or Principal Attribute after users have signed in. The principal is the key that ties a federated identity to a Prism account. Changing either value orphans every existing federated link, and each affected user's next sign-in fails until the link is re-established.

Metadata Import Failures​

Symptom: Clicking Import returns an error instead of filling in the form.

  1. The URL must be reachable from Prism's servers, not merely from your browser. An identity provider published only on an internal network, or behind a firewall that allows your workstation but not Prism, cannot be imported from. Use the Metadata XML file method instead: download the document yourself and upload it.
  2. The URL must be HTTPS. Plain HTTP and non-web schemes are refused before any request is made.
  3. A document with no identity provider descriptor is rejected rather than saved. The most common cause is pasting Service Provider metadata (including Prism's own SP metadata descriptor) into the import field. Import the identity provider's metadata document. Metadata aggregates containing more than one entity are also rejected, because there is no way to tell which entity was meant.
  4. For Microsoft Entra ID, use the per-application metadata URL. It is shown on the SAML Certificates card as App Federation Metadata Url and contains an ?appid= parameter. The tenant-wide federation metadata URL, the same URL without that parameter, does not carry the application's token-signing certificate. Importing it produces a provider that looks complete but fails every signature check.

Audience / Entity ID Mismatch​

Symptom: The identity provider refuses the request with an unknown-audience or unknown-application error, or Prism rejects the assertion's audience.

There are two identifiers, pointing in opposite directions, and both must match:

IdentifierConfigured in Prism asMust equal
Prism's own identifierSP Entity IDThe Identifier (Entity ID) registered at the identity provider
The identity provider's identifierIdP Entity IDThe Issuer the identity provider actually puts in the assertion
  1. Compare both, character for character. Trailing slashes are significant on each side. Microsoft Entra ID's issuer is https://sts.windows.net/<tenant-id>/ with a trailing slash; removing it breaks issuer validation.
  2. Check Entra's "Append application ID to issuer" option. When enabled, Entra appends the application ID to the issuer it sends, so the assertion's Issuer is no longer the plain tenant issuer that was imported into Prism. Either leave the option off, or update IdP Entity ID in Prism to the issuer Entra now sends.
  3. If SP Entity ID was overridden in Prism's advanced options, the Identifier at the identity provider must be updated to the override, not to the default value.

Clock Skew​

Symptom: Sign-in fails intermittently, for some users or at some times of day, with an assertion-not-yet-valid or assertion-expired error, and succeeds on a retry.

  1. SAML assertions carry a narrow validity window. Microsoft Entra ID adds no buffer of its own to the NotBefore timestamp, so even a small clock difference between Entra and Prism's servers puts a freshly issued assertion outside its own window.
  2. The Allowed Clock Skew field sets the tolerance in seconds. The default is 30, and the maximum accepted is 300.
  3. Raising the tolerance is a mitigation, not a fix. Investigate why the clocks differ, and keep NTP running on the hosts, before setting a large value. A wide window weakens the replay protection the timestamps exist to provide.

Microsoft Entra ID Error Codes​

Entra returns these codes on its own error page, before the user reaches Prism. The code is the fastest route to the cause.

CodeMeaningFix
AADSTS50011The reply URL in the request does not match any reply URL configured for the applicationThe ACS URL registered in Entra differs from the one Prism assigned. Matching is case-sensitive and trailing-slash-sensitive. Copy the ACS URL from Prism's Connection details dialog into Basic SAML Configuration > Reply URL. Most often the alias picked up a numeric suffix at create time and the predicted URL was never corrected.
AADSTS50105The signed-in user is not assigned to a role for the applicationAssign the user, or a group containing them, under the enterprise application's Users and groups.
AADSTS700016The application identifier was not found in the directoryThe Identifier being sent does not correspond to any application in that tenant. Check that the application still exists, that you are signing in against the right tenant, and that Prism's SP Entity ID matches the Entra Identifier (Entity ID) exactly.
AADSTS650056Misconfigured applicationUsually a stale certificate pin or an application whose identifierUris are empty. Re-check the Identifier (Entity ID) in Basic SAML Configuration and re-import the metadata so the pinned certificate matches the one Entra is currently signing with.
AADSTS75016Invalid NameIDPolicy in the SAML authentication requestThe NameID format Prism requested is not one Entra will issue for this application. Set NameID Policy Format to a format Entra supports: persistent (SAML 2.0), transient (SAML 2.0), or the SAML 1.1 emailAddress or unspecified URNs. Note the code is 75016; there is no AADSTS75006.
AADSTS75011The authentication method by which the user authenticated does not match the requested authentication methodAn authentication-context mismatch, typically caused by requesting a specific context that the user's actual sign-in did not satisfy. Review Conditional Access policies and any authentication-context requirement on the application.
AADSTS51004The user account does not exist in the directoryThe account is not in this Entra tenant, or a guest was never invited and has not accepted. Invite the guest, or sign in with an account from the tenant.

The authoritative list, including codes not shown here, is Microsoft's Microsoft Entra authentication and authorization error codes.

General SAML Checklist​

  • Reply URL / ACS URL at the identity provider matches the value in Prism's Connection details dialog exactly, including case and any trailing slash. The pre-create preview is not authoritative.
  • Identifier (Entity ID) at the identity provider matches Prism's SP Entity ID.
  • IdP Entity ID in Prism matches the Issuer the identity provider actually sends, trailing slash included.
  • The signing certificate is current, not expired, and stored as bare base64.
  • The email claim is configured in Prism under Email Attribute Name and is populated for the users who need to sign in.
  • The Principal Attribute names a claim the identity provider really sends, and has not been changed since users started signing in.
  • The users have Prism accounts with matching email addresses, and are assigned to the application at the identity provider.
  • Testing is done in a private or incognito window, and started from the Prism login page: IdP-initiated sign-in is not supported, so the identity provider's own test button will fail even on a correct configuration.

Still Having Issues?​

If none of the above solutions resolve your SSO configuration problem:

  1. Check your identity provider's documentation for additional configuration requirements.
  2. Review your IdP's audit or sign-in logs for detailed error information.
  3. Verify that the Prism instance is accessible from the network where the IdP callback will be sent.
  4. Contact CloudKeeper support with your realm name, identity provider type, and the specific error message.