This error typically indicates a mismatch between the identity provider configuration and the authentication workflow being attempted.

Common causes:

Redirect URI mismatch — The redirect URI configured in your identity provider doesn't match what FusionAuth is sending during the authentication request. The redirect URI in your authentication request must exactly match one of the Authorized Redirect URLs configured in your application's OAuth configuration.

Identity provider type misconfiguration — The identity provider type (SAML v2, OpenID Connect, etc.) may not support the redirect-based flow being used

Missing or incorrect configuration — Required fields in the identity provider configuration may be missing or misconfigured

Wrong login method selected — If you're using the /api/identity-provider/login endpoint, ensure the correct Login Method is configured in the Identity Provider settings

Flow initiated from wrong starting point — The login flow must start at FusionAuth, not directly at the external Identity Provider. Going directly to a third-party IdP URL (e.g., directly to Google or Azure OAuth URLs) bypasses FusionAuth's session handling and will fail.

Resolution steps:

Verify the identity provider configuration in FusionAuth matches your external IdP settings exactly Check that redirect URIs are correctly configured on both sides — navigate to Applications → [Your Application] → OAuth tab and ensure the Authorized Redirect URLs are properly set Confirm the identity provider type supports the authentication flow you're attempting Enable debug mode on the Identity Provider (Settings → Identity Providers → [Your IdP] → Enable debug mode) and review FusionAuth event logs (System → Event Log) for more detailed error information If this started after a recent change, review what was modified in the identity provider configuration Ensure users are starting the login flow from FusionAuth's hosted login pages or proper OAuth authorize endpoint, not bypassing FusionAuth to go directly to the external IdP

If the issue persists, gather the full error details from the FusionAuth event log with debug mode enabled and review your identity provider configuration against the FusionAuth documentation for your specific IdP type.

Related Documentation Troubleshooting Identity Provider Configuration — General troubleshooting guide for IdP issues Add an OpenID Connect Identity Provider — Configuration guide for OIDC IdPs Host a SAML v2 Identity Provider — SAML configuration and troubleshooting Enabling Debugging — How to enable debug mode for detailed error logging Identity Provider APIs — API reference for programmatic IdP configuration

The /oauth2/logout endpoint only removes the SSO session (the front-channel session controlled by the "Keep Me Signed In" toggle). It does not automatically revoke the refresh token (also known as offline_access).

To properly implement logout, you need to handle both sessions separately:

Recommended Logout Flow User initiates logout in your application Your backend revokes the refresh token using the Revoke Refresh Tokens API:DELETE /api/jwt/refresh/{refreshTokenId} Or revoke by user and application:DELETE /api/jwt/refresh?userId={userId}&applicationId={applicationId} Destroy your local application session (clear tokens, cookies, etc.) Redirect to /oauth2/logout with id_token_hint to clear the SSO session Why This Approach?

Revoking the refresh token from your application (step 2) is better than relying on the logout URL callback because:

You have direct access to the user's session data You know exactly which refresh token to revoke You can handle errors gracefully The flow is more deterministic

The /oauth2/logout endpoint can call a logout URL configured in your FusionAuth OAuth application settings, but handling revocation proactively in your app provides better control.

Important Note About JWTs

Since JWTs (access tokens) are stateless, they cannot be immediately revoked by FusionAuth. If you need to invalidate JWTs before their natural expiration, you'll need to implement your own revocation strategy, such as maintaining a token denylist in your application.

Related Documentation OAuth Logout API - Details on the /oauth2/logout endpoint Revoke Refresh Tokens API - How to revoke refresh tokens programmatically Logout and Session Management - Comprehensive guide on logout strategies and session types Revoking JWTs - Strategies for JWT revocation JWT Refresh Token Revoke Event - Webhook event when refresh tokens are revoked

The fusionauth.sso cookie is intentionally designed as a persistent cookie, which is why it has such a long Max-Age value (2147483647 seconds, approximately 68 years). The value 2147483647 is the maximum 32-bit signed integer, essentially making the cookie persistent from the browser's perspective.

However, this does not mean the cookie remains valid for 68 years. The actual validity and usability of the SSO session are controlled server-side by FusionAuth, not by the cookie's Max-Age attribute. Specifically:

The SSO session duration is configured in your Tenant settings under the OAuth tab as the Session timeout value (in seconds) FusionAuth validates whether the cookie can still be used based on these server-side SSO settings Even though the cookie persists in the browser for a long time, FusionAuth will reject it once the configured SSO session timeout has elapsed

The long Max-Age ensures the cookie isn't prematurely deleted by the browser, but the effective session lifetime is determined by your tenant's SSO configuration, not the cookie attribute itself.

The FusionAuth SSO session allows transparent authentication on one browser or device until one of the following happens:

The SSO session expires (based on the tenant's configured Session timeout) The user is logged out via the Front-Channel logout endpoint The refresh token representing the FusionAuth SSO session is revoked via an API call or the admin UI

To address penetration test findings:

Review and configure appropriate SSO session timeouts in your Tenant's OAuth settings (Tenants → Your Tenant → OAuth → Session timeout) Explain to your security auditors that the server-side session validation controls the actual security boundary, not the cookie's Max-Age. The cookie's max-age is a technical implementation detail that allows FusionAuth to manage session lifecycles server-side Demonstrate that the actual session lifetime is enforced by the configured Session timeout value, not the 68-year cookie expiration

This is a standard pattern for SSO implementations where server-side session management provides the security control rather than relying solely on cookie expiration. The browser retains the cookie, but FusionAuth enforces when that cookie is actually valid and usable for authentication.

Related Documentation Logout and Session Management - FusionAuth SSO - Comprehensive guide to how FusionAuth SSO sessions work Session Timeouts and Lifetime - Details on configuring and understanding SSO session timeouts at the tenant level Types of Session Management - Overview of different session types in FusionAuth Login Page Cookies Reference - Documentation of all cookies set by FusionAuth hosted login pages

It makes sense that this problem is happening. Once we have a SSO session on the computer/browser, then if MFA is required as part of the hosted workflows, FusionAuth will prompt for it based on the existing SSO session.

To solve this problem, you could opt to not make use of the FusionAuth SSO session. So, if you are using our Advanced themes, you could remove the option for an SSO session by removing the Keep Me Signed In checkbox from the theme. Using our Simple Themes, you would set the SSO Session to a really short duration in Tenant Settings (2 seconds, for instance) thus effectively removing the SSO session. Both of these options would eliminate this problem described above.

If you still wanted to generate a FusionAuth SSO session, and you wanted to solve this specific problem, you could use Advanced Themes and hardcode a logout link on this MFA page to allow a user to reset the session and login again. This same solution is not possible using Simple Themes, but a feature request could be logged if you wanted to see this logout link included in Simple Themes at a later date.

@dan Also, depending on the workflow, if a user does NOT federate but does NOT check "trust this computer" they will NOT establish "MFA trust". Without trust, a user will be prompted to MFA again. Of couruse, With "MFA trust", they will not be prompted. This answer is implicit to this conversation, but MFA policies and FusionAuth center around this check box and trust (with the current edge case of Federation noted).

@imsurya2442

Thanks for the question.

This may be related https://github.com/FusionAuth/fusionauth-issues/issues/2019. If it is, there is a workaround listed that you could attempt.

Thanks,
Josh

@johnathon

One approach would be to append the parameter idp_hint to the login URL to redirect a user to the appropriate IdP login page. Please read the hints section in our documentation for more information.

Another way to disable the password and email login for a user would be to set their password to a random 25-character string. This would make the password essentially impossible to brute force and thus impossible for them to log in via the hosted login page.

Use the managed domains feature. From the docs:

Adding one or more managed domains for this configuration will cause this provider not to be displayed as a button on your login page. Instead of a button the login form will first ask the user for their email address. If the user’s email address matches one of the configured domains the user will then be redirected to this login provider to complete authentication. If the user’s email address does not match one of the configured domains, the user will be prompted for a password and they will be authenticated using FusionAuth.

Documentation:

https://fusionauth.io/docs/v1/tech/identity-providers/samlv2/

https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/

@chirag have you seen these? https://fusionauth.io/learn/expert-advice/authentication/login-authentication-workflows/

Reviewing them and mapping your use case on to them may be helpful.

Generally this is a dev time message. Although depending upon your integration, it may be possible that an end user would see that message.

You could try adding a message to your theme:

[MultiTenantSSONotSupported]=n/a

In general, any user facing message can be overridden by your theme.

You’re correct. That is not a standard redirect URL. You could easily build some glue code to to look like an OpenID Connect compliant SP and then handle the redirect yourself. I am not super familiar with some of the OpenID Connect server options, but something like Hydra may be useful here. Perhaps some others from the community here can help with off the shelf options if you don’t want to code it yourself.

But coding it yourself may be the easiest, if you coded it in Node or something like that, it would be super simple, you’d have FusionAuth redirect to your node app and then you’d redirect to the video platform.

This is generally done by using the domain configuration. For example, all users with an email address domain of acme.com can be configured to use a particular SAML or OpenID Connect configuration.

As soon as you configure one IdP with a domain, the login panel will collect the email address first to understand if we need to ask for a password or forward them along to a federated identity provider.

Read more about managed domains here: https://fusionauth.io/docs/v1/tech/identity-providers/openid-connect/