ASVS 5.0 V7.1.3 (Level 2) requires you to document every system that creates or manages user sessions in a federated setup, such as an SSO provider and each application behind it, together with the controls that keep their session lifetimes, termination and reauthentication triggers aligned.
Why it matters
With SSO there are at least two sessions: one at the identity provider (IdP) and one at each relying party (RP). If they disagree, a user can log out of the IdP and stay signed in to an app for hours. Nobody can reason about that without a map.
How to implement it
Create a table in your architecture docs:
| System | Role | Session lifetime | Logout behavior | Reauth trigger |
|---|---|---|---|---|
| Corporate IdP | IdP | 8 hours | Ends IdP session | Max auth age 8h |
| Billing app | RP | 2 hours idle | Back channel logout | IdP max age exceeded |
| Admin portal | RP | 15 min idle | Back channel logout | Every sign in, step up |
Then record the mechanisms: OIDC back channel or front channel logout, the max_age or auth_time check, SAML single logout, and who owns each endpoint. Note any application that keeps its own local session after IdP logout and why.
How to test it
For each row, sign in through the IdP, end the IdP session, and check how long the application keeps working. Compare with the table. Repeat from the other direction by logging out in the application and checking the IdP.
Common mistakes
- Listing the IdP but forgetting internal apps that mint their own sessions.
- Assuming logout propagates when single logout is not actually configured.
- Leaving out third party SaaS that your IdP also fronts.
Quick check
Is this only about big SSO setups?
No. Any case where one system's login produces a session in another, including social login, counts.
