Who Owns Session Length After SSO — You or Your Customer's IdP?

Single sign-on establishes an authentication event but does not control an application’s separate session, which is created and governed by the application’s own cookies, expiry rules, revocation processes, and refresh-token policies. Because IdP and application sessions expire independently, ending or shortening an application session may merely trigger silent reauthentication through an active IdP session rather than prompt the user for credentials. SAML optionally communicates an IdP session boundary through SessionNotOnOrAfter, which service providers are advised, but not required, to honor, while OpenID Connect provides max_age, prompt=login, and auth_time mechanisms for requesting and verifying recent authentication. NIST SP 800-63B recommends different absolute and inactivity reauthentication limits by assurance level and emphasizes that activity should reset inactivity timers but not absolute session limits, while valid access or refresh tokens do not prove that a user remains present. The recommended approach is to configure session policies per tenant, cap sessions against IdP-provided limits where available, require step-up authentication for sensitive actions, carefully manage refresh-token lifetimes and revocation, and log session and reauthentication events to support security reviews and audits.

Use this post, company, and trend context to find content marketing opportunities, perform competitive analysis, or address product feature gaps via the Plushcap MCP server or the Plushcap API.