<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Why does the FusionAuth SSO cookie have a 68-year Max-Age?]]></title><description><![CDATA[<p dir="auto">During a penetration test, we received a recommendation to limit cookie lifetimes to a maximum of 14 days. However, we noticed that the <code>fusionauth.sso</code> cookie is set with an extremely long <code>Max-Age</code> value:</p>
<pre><code>set-cookie: fusionauth.sso=&lt;redacted&gt;; HttpOnly; Max-Age=2147483647; Path=/; SameSite=Lax; Secure
</code></pre>
<p dir="auto">This <code>Max-Age</code> value of <code>2147483647</code> 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?</p>
]]></description><link>https://fusionauth.io/community/forum/topic/3163/why-does-the-fusionauth-sso-cookie-have-a-68-year-max-age</link><generator>RSS for Node</generator><lastBuildDate>Thu, 08 Oct 2026 01:03:27 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/topic/3163.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 28 Sep 2026 21:12:28 GMT</pubDate><ttl>60</ttl><item><title><![CDATA[Reply to Why does the FusionAuth SSO cookie have a 68-year Max-Age? on Mon, 28 Sep 2026 21:12:39 GMT]]></title><description><![CDATA[<p dir="auto">The <code>fusionauth.sso</code> cookie is intentionally designed as a <strong>persistent cookie</strong>, which is why it has such a long <code>Max-Age</code> value (2147483647 seconds, approximately 68 years). The value <code>2147483647</code> is the maximum 32-bit signed integer, essentially making the cookie persistent from the browser's perspective.</p>
<p dir="auto">However, this does not mean the cookie remains valid for 68 years. The actual validity and usability of the SSO session are controlled <strong>server-side by FusionAuth</strong>, not by the cookie's <code>Max-Age</code> attribute. Specifically:</p>
<ul>
<li>The SSO session duration is configured in your <strong>Tenant settings</strong> under the <strong>OAuth tab</strong> as the <strong>Session timeout</strong> value (in seconds)</li>
<li>FusionAuth validates whether the cookie can still be used based on these server-side SSO settings</li>
<li>Even though the cookie persists in the browser for a long time, FusionAuth will reject it once the configured SSO session timeout has elapsed</li>
</ul>
<p dir="auto">The long <code>Max-Age</code> ensures the cookie isn't prematurely deleted by the browser, but the <strong>effective session lifetime is determined by your tenant's SSO configuration</strong>, not the cookie attribute itself.</p>
<p dir="auto">The FusionAuth SSO session allows transparent authentication on one browser or device until one of the following happens:</p>
<ul>
<li>The SSO session expires (based on the tenant's configured Session timeout)</li>
<li>The user is logged out via the Front-Channel logout endpoint</li>
<li>The refresh token representing the FusionAuth SSO session is revoked via an API call or the admin UI</li>
</ul>
<p dir="auto"><strong>To address penetration test findings:</strong></p>
<ol>
<li><strong>Review and configure appropriate SSO session timeouts</strong> in your Tenant's OAuth settings (Tenants → Your Tenant → OAuth → Session timeout)</li>
<li><strong>Explain to your security auditors</strong> that the server-side session validation controls the actual security boundary, not the cookie's <code>Max-Age</code>. The cookie's max-age is a technical implementation detail that allows FusionAuth to manage session lifecycles server-side</li>
<li><strong>Demonstrate that the actual session lifetime</strong> is enforced by the configured Session timeout value, not the 68-year cookie expiration</li>
</ol>
<p dir="auto">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.</p>
<h2>Related Documentation</h2>
<ul>
<li><a href="https://fusionauth.io/docs/lifecycle/authenticate-users/logout-session-management#fusionauth-sso" rel="nofollow ugc">Logout and Session Management - FusionAuth SSO</a> - Comprehensive guide to how FusionAuth SSO sessions work</li>
<li><a href="https://fusionauth.io/docs/lifecycle/authenticate-users/logout-session-management#session-timeouts-and-lifetime" rel="nofollow ugc">Session Timeouts and Lifetime</a> - Details on configuring and understanding SSO session timeouts at the tenant level</li>
<li><a href="https://fusionauth.io/docs/lifecycle/authenticate-users/logout-session-management#types-of-session-management" rel="nofollow ugc">Types of Session Management</a> - Overview of different session types in FusionAuth</li>
<li><a href="https://fusionauth.io/docs/reference/cookies#cookie-list" rel="nofollow ugc">Login Page Cookies Reference</a> - Documentation of all cookies set by FusionAuth hosted login pages</li>
</ul>
]]></description><link>https://fusionauth.io/community/forum/post/8664</link><guid isPermaLink="true">https://fusionauth.io/community/forum/post/8664</guid><dc:creator><![CDATA[FASupportBot]]></dc:creator><pubDate>Mon, 28 Sep 2026 21:12:39 GMT</pubDate></item></channel></rss>