SSO/SAML会话闲置2分钟超时排查：Devise配置15分钟仍失效？
Hey there, let's break down why your SSO users are getting kicked out after 2 minutes of inactivity—even with Devise's timeout_in set to 15 minutes and valid tokens. Here are the most likely culprits to check:
1. Identity Provider (IdP) Session Timeout Configuration
The most common culprit here is that your SAML IdP (like Okta, ADFS, Azure AD) has its own session idle timeout set to 2 minutes. SSO sessions are often controlled by the IdP, not just your service provider (SP) app.
- Log into your IdP's admin console and look for settings like "Session Idle Timeout", "Inactivity Timeout", or "SAML Session Duration".
- Ensure this matches your desired 15-minute window—many IdPs default to short timeouts for security, so it's easy to miss.
2. SAML Assertion Expiry Overrides Devise Settings
Devise's config.timeout_in manages local app sessions, but SAML-authenticated users rely on the expiry claims in the SAML assertion sent by the IdP. Check if the assertion includes:
SessionNotOnOrAfter: Controls the maximum lifetime of the SSO sessionNotOnOrAfter: Controls the validity period of the assertion itself
If either of these is set to 2 minutes after authentication, your user will be logged out once that timestamp passes—regardless of Devise's settings. To verify this, you can:
- Enable SAML logging in your app (most SAML gems support this) to inspect the raw assertion response
- Use a browser extension like SAML Tracer to capture and analyze the SAML response payload
3. Rails Session Cookie Timeout Takes Priority
Rails has its own session cookie configuration that might override both Devise and SAML settings. Check your config/initializers/session_store.rb file for an expire_after parameter:
Rails.application.config.session_store :cookie_store, key: '_your_app_session', expire_after: 2.minutes
If this is set to 2 minutes, the session cookie will expire after that window, forcing a logout even if Devise and SAML are configured correctly. Update this to match your 15-minute timeout.
4. SAML SP Gem Configuration Overrides Devise
If you're using a gem like devise_saml_authenticatable, it might have its own session expiry settings that take precedence over Devise's timeout_in. Look for config options in config/initializers/devise.rb like:
config.saml_session_expiry = 2.minutes
Make sure this is set to 15.minutes to align with your desired timeout. Also, check if the gem has an option to sync session expiry with the IdP's SessionNotOnOrAfter claim—some gems default to honoring the IdP's value over local settings.
5. Idle Activity Detection Misalignment
Devise's timeout_in tracks the user's last request to your app, but some IdPs track idle time based on interactions with the IdP itself. For example:
- If your app doesn't trigger any SAML re-authentication or token refresh during user activity, the IdP might consider the user idle after 2 minutes.
- Check if your app has frontend logic that keeps the session alive (like periodic AJAX requests) or if the IdP requires active interaction to reset the idle timer.
内容的提问来源于stack exchange，提问作者JohnSmith
