Depending on the complexity of your authentication setup, you or your users may occasionally encounter errors.
Here are some common error codes and troubleshooting steps.
This error message typically appears when there’s an issue with your authentication configuration or token handling. A few common causes include:
- Expired or invalid tokens
- Misconfigured authentication settings
- Session management issues
- Incorrect callback URLs
The State not found error typically occurs when there’s a mismatch between your environment variables and the domain you’re using during authentication. There may be a trailing space or incorrect syntax.
A 403 Forbidden response from the JWKS endpoint (/.well-known/jwks) means the request was rejected before the public keys could be returned. Common causes include:
- Wrong domain or subdomain - Ensure you are fetching the JWKS endpoint from your correct Kinde domain (e.g.
https://your-business.kinde.com/.well-known/jwks). A typo or incorrect region subdomain will result in a 403.
- Unexpected credentials in the request - The JWKS endpoint is public and does not require authentication. Sending unexpected or invalid credentials (e.g. an expired client secret or an Authorization header) can cause the request to be rejected. Remove any authorization headers from JWKS fetch requests.
- CORS misconfiguration - Browser-based applications that fetch JWKS directly may hit CORS restrictions. Perform the JWKS fetch server-side where possible, or verify that your origin is permitted in your Kinde application settings.
- IP allowlist or firewall rules - If your environment or network applies IP restrictions, check that outbound requests to your Kinde domain are not being blocked before they reach the endpoint.
Verification codes are sent almost immediately when triggered. If a code is not received, it might be because:
- Junk/spam folders - Email providers and devices may treat OTPs from unknown providers like Kinde as spam. Check your own spam folder, or ask your IT team if emails from Kinde are quarantined by firewalls or other IT defence systems.
- Gmail delays - Google Workspace addresses can experience ~4-minute-delays due to pre-delivery scanning
- Microsoft Defender filters - Aggressive anti-spam filters sometimes quarantine verification emails for Outlook/Hotmail users
If none of the above help troubleshoot the issue, contact Kinde support.
Verification codes are sent almost immediately when triggered. If a code is not received, it might be because:
- Network connectivity problems or poor signal strength
- Carrier-level spam filtering blocking OTP messages
- SMS delivery delays during peak usage times
- Full storage preventing new messages from being received
- Phone numbers in certain countries do sometimes experience issues. Contact us if you think this might be the case.
We recommend using Twilio, a third-party SMS provider instead of Kinde’s default service. This makes troubleshooting issues and accessing logs much easier.
Description
- This code can appear in the verification link inside a Kinde email verification email
Troubleshooting
- Verification links are time-limited. If the link has expired, request a new verification email and use it promptly
- Make sure the link is opened in the same browser and session in which the verification was requested
- If the error persists after requesting a fresh link, contact Kinde support with the full error code and the email address being verified
Description
- Error coming back to Kinde while validating SAML response
Troubleshooting
- Check that the Assertion Consumer Service (ACS) URL is correct on the identity provider
Description
- The OAuth 2.0 response failed
- The token is valid, but the redirect is null
Description
- Error getting or reading the connected app configuration
Description
- Error getting custom SAML config while initializing SAML redirect
Description
- Error with authorization response
- The request is missing a required parameter, includes an invalid parameter value, includes a parameter more than once, or is otherwise malformed
Troubleshooting
- Missing nonce on implicit flow
- Redirect URI might not be with an https
- Only a localhost suffix can be used with http
- Error with workflow
Description
Troubleshooting
- Review the post-authentication workflow configuration for missing data references, inactive integrations, or misconfigured conditions
- Disable non-essential workflow steps one at a time and retry login to isolate the failing step
- If you need to unblock users while investigating, change the policy setting from
stop to warn or allow
- If the workflow was recently modified, restore the previous version using the version history in the workflow settings
Description
- The
state value returned on the social sign-in (OAuth 2.0) callback could not be decrypted or validated
- This usually means the state was tampered with, truncated, expired, or came from a different environment or domain
Troubleshooting
- Start the sign-in flow again from the sign-in or log-in button, rather than from a bookmarked or partially completed auth URL
- Make sure the domain or region you are using matches your Kinde environment exactly — see the State not found section for related mismatch causes
- Retry in a fresh browser session
Description
- Error exchanging token on connected app callback
Troubleshooting
- Check the redirect URLs for a mismatch
- Check the client credentials
Description
- Error decoding SAML response
- Response contains invalid characters for Base64 response
Description
Troubleshooting
- The workflow is intentionally blocking the user based on a matched condition — this is not a workflow error
- Review the post-authentication workflow conditions to identify which rule is triggering the denial and update it if needed
Description
- Cannot handle SAML callback
- The userProfile contains invalid values
Description
- OAuth 2.0 response failed because token is invalid and redirect ID is null
Description
- Social sign-in (OAuth 2.0 callback) was stopped at the identity provider before a token could be issued
- The provider returned
access_denied — typically the user cancelled the sign-in, or an organization/provider policy (such as Microsoft Entra Conditional Access) blocked it
Troubleshooting
- This is often expected (the user closed or declined the provider’s consent screen). Ask the user to try signing in again.
- If it affects all users on a connection, review the social connection’s app and consent configuration at the provider, and any organization policies that may be blocking access.
Description
- Social sign-in could not complete because the identity provider requires further interaction
- The provider returned
interaction_required, login_required, consent_required, or account_selection_required
Troubleshooting
- Ask the user to start the sign-in again and complete any prompts (login, consent, or account selection) shown by the provider.
- This commonly occurs on silent or SSO attempts where the provider needs an interactive session.
Description
- The identity provider was temporarily unavailable during the social sign-in callback
- The provider returned
temporarily_unavailable or server_error
Troubleshooting
- Wait a moment and try signing in again.
- If it continues, check the identity provider’s status page for an outage.
Description
- The identity provider returned an unrecognized error during the social sign-in (OAuth 2.0) callback
Troubleshooting
- Retry the sign-in.
- If it persists, review the social connection configuration and contact Kinde support with the error code and the provider’s
error/error_description from your logs.
Description
- The social sign-in (OAuth 2.0) callback arrived with neither an authorization code nor an error
- The cross-site form post lost its body in transit on some clients, so there was nothing to exchange
Troubleshooting
- Ask the user to start the sign-in again.
- This is more likely on browsers or privacy settings that strip cross-site POST bodies — ensure cross-site requests and cookies required for the auth flow are not being blocked.
Description
- Handle Social OAuth 2.0 callback - error exchanging token
- Expired secrets for social provider
Troubleshooting
- Check the secret being used with your social provider and ensure that it hasn’t expired
Description
- Error reading config on OAuth 2.0 callback
Troubleshooting
- Check that the client credentials in both Kinde and IDP are correct
- Check that the redirect and callback URLs in both Kinde and IDP are correct
Description
- OAuth 2.0 response failed due to an invalid token
- Redirection was successful
Description
- Error configuring SAML provider
This error can appear if IdP-initiated SSO is attempted but not properly configured. Kinde supports both SP-initiated (default) and IdP-initiated SSO flows. If you need IdP-initiated SSO, ensure it’s properly configured. See IdP-initiated SAML SSO for setup instructions.
Troubleshooting
- Check that the settings in the Kinde enterprise connection are correct
- Check enterprise connection metadata URL, entity ID, certificate
- If using IdP-initiated SSO, verify the IdP is configured to send assertions to the correct ACS URL
Description
- SAML callback tokenInfo returned invalid data
Description
- Error configuring SAML provider on redirect
Troubleshooting
- Check the enterprise connection metadata URL
- Check that the IDP has the correct ACS URL
Description:
- Received browser trust token is different from the one stored in the login session
Troubleshooting
- Start the auth flow again from the sign in or log in button
- The user is trying to start a session in a new tab, browser, or device when there’s already a partially completed session in progress
- The user may have bookmarked the auth page when it’s partially completed, instead of bookmarking the initial sign in or log in page
Description
- During the social sign-in (OAuth 2.0) callback, Kinde could not complete the organization or environment transfer redirect
Troubleshooting
- Retry the sign-in
- If it persists, contact Kinde support with the error code and the
psid value from the URL
Description
- Error getting custom SAML provider configuration
- RelayState is invalid or doesn’t exist
Troubleshooting
- Check the SAML callback URL
- Check the entity ID
- Check that the SAML IDP is returning a valid RelayState
Description
- Error getting authentication request while initializing SAML redirect
Troubleshooting
- Check the enterprise connection private key, certificate, and signature method
Description
- Disposable email detected while authenticating a user on sign up in a workflow
Description
- Error storing tokens with connected app
Troubleshooting
- Check the refresh token is valid