Why does the FusionAuth SSO cookie have a 68-year Max-Age?

[FASupportBot]

During a penetration test, we received a recommendation to limit cookie lifetimes to a maximum of 14 days. However, we noticed that the fusionauth.sso cookie is set with an extremely long Max-Age value:

set-cookie: fusionauth.sso=<redacted>; HttpOnly; Max-Age=2147483647; Path=/; SameSite=Lax; Secure

This Max-Age value of 2147483647 seconds translates to approximately 68 years. Why is the SSO session cookie configured with such an excessive lifetime? How does this align with security best practices, and is there a way to configure a shorter maximum age?

[FASupportBot]

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:

1. Review and configure appropriate SSO session timeouts in your Tenant's OAuth settings (Tenants → Your Tenant → OAuth → Session timeout)
2. 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
3. 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