Once an authentication event has taken place, it is often desirable to allow the user to continue using the application across multiple subsequent interactions without requiring the user to repeat the authentication event every time. This requirement is particularly true for federation scenarios (described in volume C), where the authentication event necessarily involves several components and actors coordinating across a network.
To facilitate this behavior, a session MAY be started in response to an authentication event, and such a session SHALL continue until such time that it is terminated. The session MAY be terminated for any number of reasons, including but not limited to an inactivity timeout, an explicit logout event, or other means. The session MAY be continued through a reauthentication event (described in section 7.2), wherein the user repeats some or all of the initial authentication event, thereby asserting their presence again.
Session management is preferable over continuous presentation of credentials as the usability requirements of such continuous presentation would incentivize workarounds such as cached unlocking credentials, negating the freshness of the authentication event in the first place.
A session occurs between the software that a subscriber is running, such as a browser, application, or operating system (the session subject), and the RP or CSP that the subscriber is accessing (the session host). A session secret SHALL be shared between the subscriber’s software and the service being accessed. This secret binds the two ends of the session, allowing the user to continue using the service over time. The secret MAY be presented directly by the user’s software (a bearer secret) or possession of the secret MAY be proven using a cryptographic mechanism (a proof of possession secret).
The secret used for session binding SHALL be generated by the session host in direct response to an authentication event. A session SHOULD inherit the AAL properties of the authentication event which triggered its creation; a session MAY be considered at a lower AAL than the authentication event and SHALL NOT be considered at a higher AAL than the authentication event.
Secrets used for session binding:
URLs or POST content SHALL contain a session identifier that SHALL be verified by the relying party to ensure that actions taken outside the session do not affect the protected session.
There are several different mechanisms for managing a session over time. The following sections give three examples, along with additional requirements and considerations particular to each example technology.
Browser cookies are the predominant mechanism by which a session will be created and tracked for a user accessing a service.
Cookies:
An OAuth access token is be used to allow an application to access a set of services on behalf of a user following an authentication event. The presence of an OAuth access token SHALL NOT be interpreted by the RP to indicate the presence of the user, in the absence of other signals. The OAuth access token (and any associated refresh tokens) MAY be valid long after the authentication session has ended and the user has left the application in question.
Other methods of secure device identification, including but not limited to mutual TLS, token binding, or other mechanisms, MAY be used to enact a session between a user and a service.
A session SHALL NOT be extended past the guidelines in sections 4.1.4, 4.2.4, and 4.3.4 (depending on AAL) based on presentation of the session secret alone.
When a session is terminated due to a time-out or other action, the user MAY reauthenticate using their primary authentication mechanism or an appropriate subset thereof, depending on the AAL.
Table 7-1. AAL Reauthentication Requirements
| AAL | Requirement |
|---|---|
| 1 | Presentation of any one factor |
| 2 | Presentation of a memorized secret or biometric |
| 3 | Presentation of all factors |
Note: At AAL 2, a memorized secret or biometric and not a physical authenticator is required because the session secret is something you have, and an additional authentication factor is required to continue the session.
When using a federation protocol to connect the CSP and RP, special consideration needs to be made for session management and reauthentication. Both the CSP and RP employ separate session management technologies, and there SHALL NOT be any assumption of correlation between these sessions. Consequently, when a session expires at an RP and reauthentication is required by the RP, it is entirely possible that the session at the CSP is not expired and a new assertion could be generated from this session at the CSP without reauthenticating the user. Therefore, an RP requiring a reauthentication through a federation protocol SHALL indicate a minimum acceptable authentication age to the CSP (if possible within the protocol), and the CSP SHALL honor this request (if possible). The CSP in all cases SHALL communicate the primary authentication event time to the RP to allow the RP to decide if the assertion is sufficient for reauthentication or not.