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

To revoke all active user sessions and access tokens immediately during a security incident, you need to take a two-pronged approach: revoking sessions (refresh tokens) and invalidating access tokens.

1. Revoke All Sessions (Refresh Tokens)

Sessions in FusionAuth are represented by refresh tokens, and these can be directly revoked using the API:

Revoke all refresh tokens for all users in an application:

DELETE /api/jwt/refresh?applicationId={applicationId}

Revoke all refresh tokens for a specific user:

DELETE /api/jwt/refresh?userId={userId}

Revoke all refresh tokens for a specific user in a specific application:

DELETE /api/jwt/refresh?applicationId={applicationId}&userId={userId}

These API calls require an API key with appropriate permissions. When refresh tokens are revoked, users will be unable to obtain new access tokens and will need to re-authenticate.

2. Invalidate Access Tokens via Key Rotation

To invalidate access tokens (not just refresh tokens), you need to rotate the JWT signing keys:

In FusionAuth: Rotate the JWT signing keys used by your tenant/application. This will cause all subsequently validated tokens signed with the old key to fail validation.

In your application server: Update your application to use the new signing key for validating incoming JWTs. This ensures that tokens signed with the old key are no longer trusted.

This approach effectively invalidates all active access tokens because they were signed with the now-rotated key. When your application validates these tokens using the new key, validation will fail and users will need to re-authenticate.

Important Considerations Access tokens are stateless JWTs by design, so they cannot be revoked individually from FusionAuth's side once issued. This is why key rotation is the standard mechanism to invalidate all tokens at once. Key rotation is immediate and forceful: All existing access tokens become invalid immediately upon rotation, making this the appropriate response for security incidents. Ensure your application is updated to accept the new signing key before or immediately after rotation to prevent service disruption for legitimate re-authentication attempts. Short access token lifetimes (minutes, not hours) are strongly recommended as a defense-in-depth measure, since access tokens cannot be individually revoked. Use webhooks to notify your resource servers when refresh tokens are revoked, allowing them to maintain a blocklist of affected users if additional control is needed before access tokens naturally expire. Alternative: Maintain a Revocation List

For access tokens still within their validity period after key rotation, you can implement an application-level revocation mechanism:

Subscribe to the JWT Refresh Token Revoke webhook event When refresh tokens are revoked, record the affected users/tokens On each request, check if the user's token has been revoked before processing

This provides additional granular control but requires application-level implementation.

Related Documentation Revoke Refresh Tokens API - API for revoking refresh tokens by user, application, or token ID Key Rotation - Complete guide to rotating keys in FusionAuth, including JWT signing keys JWT Refresh Token Revoke Event - Webhook event triggered when refresh tokens are revoked Logout and Session Management - Overview of session management approaches in FusionAuth Can I Revoke an Access Token? - Community discussion on access token revocation limitations Configuring JWT Signing - How to configure JWT signing keys at the tenant and application level