What problem does the re-authentication criterion solve, and how does it differ from the relying party's own session management?
It ensures that, in a running session, the subject is still the same one the identity provider authenticated at the start, by forcing a fresh authentication at the IdP after a maximum time, regardless of how the RP manages its own sessions.
Once a user has logged in, a relying party usually keeps a session alive with a cookie. That cookie proves only that some browser logged in at some point. The person may have walked away from an unlocked computer, or the session cookie may have been stolen. The longer a session lives, the weaker its link to the original authentication.
The criterion therefore asks two questions:
- After what time must an RP, independently of its own session management, have the subject re-authenticated by the IdP?
- How can it be ensured in a running session that the subject is still the same as at the initial authentication?
This is different from the RP's own session rules, such as logging out after 5 minutes of inactivity, after a maximum session time, or before a sensitive action like saving data. Those are application decisions. The re-authentication interval is the upper bound set by the trust level: an RP claiming that level must send an active user back to the IdP at least that often, even if its own rules would allow longer. In OAuth terms, for instance, refresh tokens must not be renewable forever.
Go deeper:
NIST SP 800-63B-4: Reauthentication — why sessions need overall and inactivity timeouts.