SSO Configuration Issues
This page covers common problems with setting up and managing identity provider (IdP) integrations in Prism, including Google OAuth, Microsoft OAuth, and custom OIDC 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:
- 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.
- Test the Authorization URL by pasting it directly into your browser. You should see the IdP login page.
- Ensure the identity provider is enabled (not in a draft or disabled state).
- 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:
- In the Admin Portal under Identity Providers, verify the Client ID matches exactly with your IdP configuration. Copy and paste to avoid typos.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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
- Go to Google Cloud Console > APIs & Services > Credentials.
- Select the OAuth 2.0 Client ID used for Prism.
- 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.
- Ensure the URI matches exactly, including the protocol (
https://) and path. Trailing slashes matter. - After saving changes in Google Console, wait a few minutes for the changes to propagate.
"access_denied" Error
- Verify that the Google Workspace admin has not restricted which applications can access user data.
- If your organization uses Google Workspace, the OAuth app may need to be marked as "trusted" in the Workspace admin console.
- 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
- Go to Azure Portal > Azure Active Directory > App registrations.
- Select the Prism application.
- Under Authentication > Redirect URIs, add the exact callback URL from Prism's Identity Provider configuration page.
- Ensure the URI type is "Web" (not "SPA" or "Mobile").
- Save the changes and wait a few minutes for propagation.
"AADSTS700016" - Application Not Found
- Verify the Client ID (Application ID) in Prism matches the one shown in Azure AD.
- Check that the app registration has not been deleted.
- If your organization uses multiple Azure AD tenants, ensure you are looking at the correct tenant.
Consent Errors
- If users see a consent prompt they cannot approve, an Azure AD administrator may need to grant admin consent for the application.
- Go to App registrations > API permissions and click Grant admin consent.
- 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
- 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.
- Test the endpoints by opening the Issuer URL in a browser. Many providers serve a discovery document at
{issuer}/.well-known/openid-configuration. - Ensure all endpoints are reachable from Prism's servers (no firewall or VPN restrictions).
- Use the Validate button on the Custom IdP configuration page to verify the endpoints before saving.
Claims Mapping
- After a successful login, if user attributes (name, email) are not populated correctly, the claims mapping may be incorrect.
- Verify that your OIDC provider returns the expected claims:
emailfor the user's email addressgiven_nameandfamily_namefor the user's name (ornamefor the full name)subfor the unique user identifier
- 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.
Still Having Issues?
If none of the above solutions resolve your SSO configuration problem:
- Check your identity provider's documentation for additional configuration requirements.
- Review your IdP's audit or sign-in logs for detailed error information.
- Verify that the Prism instance is accessible from the network where the IdP callback will be sent.
- Contact CloudKeeper support with your realm name, identity provider type, and the specific error message.