Skip to main content
Version: latest

I cannot log in with SSO

VaultPAM supports Single Sign-On (SSO) via OpenID Connect (OIDC). When SSO login fails, the root cause is almost always one of five categories: OIDC misconfiguration, clock skew between VaultPAM and the IdP, the user not being provisioned in the Identity Provider, an incorrect redirect URI, or a Keycloak realm setting. Admins should work through these in order — OIDC misconfiguration is by far the most common cause.

Symptoms​

  • The SSO button on the login page redirects to the Identity Provider but then returns an error.
  • Error messages you may see:
    • invalid_client or unauthorized_client
    • redirect_uri_mismatch
    • access_denied
    • invalid_grant: Session not active
    • User not found or Account is not fully set up
    • A generic "Something went wrong" page after a redirect back from the IdP
  • The user can authenticate on the IdP side but VaultPAM does not log them in.

Causes​

1. OIDC misconfiguration​

The Client ID, Client Secret, or OIDC discovery URL configured in VaultPAM does not match what the Identity Provider has registered.

Check: In Organization → Security → SSO Settings, verify:

  • OIDC Issuer URL resolves and returns a valid .well-known/openid-configuration document.
  • Client ID matches exactly what is registered in the IdP application.
  • Client Secret has not been rotated on the IdP side without updating VaultPAM.

Fix: Update the mismatched field and save. Test by attempting SSO login again.

2. Clock skew between VaultPAM and the IdP​

OIDC tokens contain iat (issued-at) and exp (expiry) claims. If the clocks on the VaultPAM server or the IdP are more than ±60 seconds apart, token validation fails with an invalid_grant or "Session not active" error.

Check: On the VaultPAM host (or Kubernetes node), run:

date -u

Compare against the IdP's clock (visible in the iat claim of a decoded JWT, or checked via the IdP admin console). The difference must be under 60 seconds.

Fix: Ensure both systems synchronise their clocks against an NTP source. On Linux: timedatectl set-ntp true. In Kubernetes, the node clock is inherited from the VM host — ensure the hypervisor layer has NTP configured.

3. User not provisioned in the IdP​

The user's account exists in VaultPAM but has not been created or activated in the Identity Provider, or the IdP account email does not match the VaultPAM account email.

Check: In the IdP admin console, confirm the user account exists and is active. Verify the email address matches exactly (case-sensitive match applies in some IdPs).

Fix: Create or activate the user account in the IdP, or update the email address in either system to ensure they match. If your org uses SCIM provisioning, confirm the provisioning connector is active and the user belongs to the provisioned group.

4. Wrong redirect URI​

The redirect URI that VaultPAM sends during the OIDC Authorization Code flow must match one of the allowed redirect URIs registered in the IdP application exactly. Even a trailing slash difference causes a redirect_uri_mismatch error.

Check: In Organization → Security → SSO Settings, note the Callback URL displayed. Open the IdP application registration and verify this exact URI is listed in the allowed redirect URIs.

Fix: Add the exact callback URL to the IdP application's allowed redirect URI list and save.

5. Keycloak realm settings​

When VaultPAM uses an embedded or self-hosted Keycloak instance, misconfigured realm settings can prevent login even when the OIDC client is correctly configured.

Common Keycloak-specific issues:

  • The realm is disabled or in read-only mode.
  • The client's Access Type is set to public when VaultPAM expects confidential.
  • The required openid, email, or profile scopes are not mapped in the client.
  • Valid Redirect URIs in the Keycloak client does not include the VaultPAM callback URL.

Check: Open the Keycloak admin console, navigate to Realms → [realm name] → Clients → [VaultPAM client], and verify:

  • Client is Enabled.
  • Access Type is confidential.
  • Valid Redirect URIs includes the VaultPAM callback URL.
  • Client Scopes include openid, email, and profile.

Fix: Correct the Keycloak client settings and save. No restart is required for most Keycloak configuration changes.

Resolution steps​

  1. Open Organization → Security → SSO Settings and verify the OIDC Issuer URL, Client ID, and Client Secret match the IdP application registration exactly.
  2. Check the server clocks on the VaultPAM host and IdP. If skew exceeds 30 seconds, configure NTP on both systems.
  3. In the IdP admin console, confirm the user account exists, is active, and the email matches the VaultPAM account email.
  4. Confirm the Callback URL shown in Organization → Security → SSO Settings is listed as an allowed redirect URI in the IdP application.
  5. If using Keycloak, open the Keycloak admin console and verify the client is enabled, the access type is confidential, valid redirect URIs include the callback URL, and the required scopes are mapped.
  6. After any change, clear your browser cookies and retry SSO login from a private/incognito window to avoid cached session state.

Escalation path​

If you have worked through all five causes and SSO login still fails:

  1. Capture the full URL shown in the browser address bar at the point of failure (it contains the error code and description as query parameters).
  2. Collect the Keycloak or IdP event log for the failed authentication attempt.
  3. Note the exact error message visible on screen.
  4. Open a support ticket with: your IdP type and version, the error URL, the event log snippet, and confirmation of which steps you have already completed.