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

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

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.

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.

Important Note: FusionAuth does not currently implement RFC 8693 (OAuth 2.0 Token Exchange) natively. There is an open GitHub issue tracking this feature request. However, FusionAuth provides alternative approaches to achieve similar outcomes.

Since RFC 8693 isn't supported yet, here are the recommended approaches:

Use the Issue a JWT endpoint to exchange a token from one application for a token for another application. This is FusionAuth's implementation of SSO for access tokens:

This returns a new JWT with the target application's audience, preserving the user's identity. The user must be registered in both applications.

Use a JWT Populate Lambda to customize the aud claim directly. You can add multiple audiences to avoid token swapping:

For more complex delegation scenarios, use the Vend a JWT endpoint to create a custom JWT with free-form claims (except reserved claims like iat, exp, amr, and cnf).

This approach avoids re-authentication and cleanly separates concerns: the user holds their web token, and the agent dynamically obtains the correct token for each downstream service it needs to call.

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 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:

To address penetration test findings:

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.

Important Clarification: FusionAuth does not currently support RFC 8693 token exchange natively. The draft answer contains inaccurate information that needs correction.

Current RFC 8693 Status:

Workarounds for Token Exchange and Impersonation:

While native RFC 8693 support is unavailable, FusionAuth offers alternative approaches:

You can use FusionAuth's Vend a JWT endpoint to create custom tokens that include an act claim, following RFC 8693 delegation chain semantics:

This approach provides delegation semantics where the original actor is tracked in the act claim.

For pure impersonation (without delegation tracking), you can implement this at the API level:

Note: Impersonation via the OAuth/OIDC workflow is not supported as it would conflict with the OAuth specification.

Recommendation:
If standards-compliant RFC 8693 token exchange is a hard requirement for your migration, you may want to track or upvote the GitHub issue mentioned above. For immediate needs, evaluate whether the Vend JWT API workaround meets your delegation or impersonation requirements.

Root cause:

When a user clicks the password reset link from their email, the link doesn't include response_type=code in the URL. Normally, FusionAuth adds this parameter automatically during the OAuth flow.

However, when the user already has an active login session in their browser (even though their MFA trust has expired), FusionAuth detects that session and takes a shortcut. Instead of starting a fresh OAuth flow where it would add response_type=code automatically, it attempts to reuse the existing session's OAuth state.

This saved OAuth state is incomplete and missing the response_type parameter. When FusionAuth tries to redirect back to the application after MFA verification, it encounters an OAuth error because response_type was never included in the saved state.

Temporary workaround:

Manually add response_type=code to the password reset URL until a proper fix is available. While this works, it's a band-aid solution.

Status:

This issue appears to have been introduced in a version before 1.69.2 and may require a bug fix from the FusionAuth product team to properly handle OAuth state in password reset flows when active sessions are present. There's currently no tracking GitHub issue that I'm aware of.

The slightly trickier part here is only having the username/password field show up for that user. The only way to accomplish this with Simple Themes would be to have managed domains setup such that all normal users are directed to IdPs but the break glass user is on a separate domain so they get to see the login page. With managed domains, the login field changes just to email address for the first step. Then it will check the users email address against domains you have setup for specific IdPs and if they match a IdP then a user is directed straight to that IdP. Any user with a domain that does not match gets sent to the regular email/password login page.

https://fusionauth.io/docs/extend/code/lambdas/login-validation

https://fusionauth.io/docs/extend/events-and-webhooks/events/user-login-success

https://fusionauth.io/docs/lifecycle/authenticate-users/identity-providers/#managed-domains

However, there’s a workaround if you’d like to simulate a passwordless experience. Using the Advanced Theme Editor, you can hide and automatically populate the password field on the registration page via JavaScript. This way, users won’t see or interact with the password field, but FusionAuth still receives a valid (though randomly generated) password value behind the scenes. To users, the experience feels passwordless, even though a hidden dummy password exists for each account.

More details about customizing the registration page can be found here:
Advanced Theme Editor Documentation

Events That Count as a "Login":

For more details, refer to:
What Makes a User Active?

1. Understanding the Registration URL with PKCE

The /oauth2/register endpoint works similarly to the /oauth2/authorize endpoint but is used for user registration. Both support PKCE.
Example URLs:

Since PKCE is enabled, you must append PKCE parameters:

2. Generating PKCE Parameters

Your application must generate a code_verifier and code_challenge before redirecting to FusionAuth’s registration page.

Node.js Example:

3. Constructing the Registration URL

Once you have the code challenge, construct the registration URL as follows:

4. Completing the PKCE Flow After Registration

After the user completes registration, FusionAuth will redirect them to your app with an authorization code.
Your app must then exchange this code for an access token by sending the code_verifier to /oauth2/token.

For full details on the PKCE flow, see:

Summary

Events That Count as a "Login":

For more details, refer to:
What Makes a User Active?

As documented here: https://fusionauth.io/docs/v1/tech/oauth/endpoints#userinfo we don't provide the address info, even if you pass the address scope.

Per the OpenID spec, section 5.4, it appears that supporting the address scope is optional: https://openid.net/specs/openid-connect-core-1_0.html#ScopeClaims

If this is important to you, please file an issue here: https://github.com/fusionauth/fusionauth-issues/issues with details about the use case.

We are guided by our customers and community when it comes to implementation of issues. Here's our general roadmap guidance: https://fusionauth.io/docs/v1/tech/core-concepts/roadmap

You will want to review our linking strategies. When this occurs, oftentimes, this is due to custom mapping needed (you can see this in our discord doc).

The event log is another great place to look to see how your user is or is not being linked/created.

You can also look at our doc for discord as an IDP

Hope this helps!
Josh

44545473-38b0-41a8-a6ab-e581c7bd04b2-image.png