This section is normative.
Once an authentication event has occurred, it is often desirable to allow the subscriber to continue using the application across multiple subsequent interactions without requiring them to repeat the authentication event. This is particularly the case with federation scenarios (described in [SP800-63C]) in which the authentication event necessarily involves the coordination of several components and parties across a network.
To facilitate this behavior, a session MAY be started in response to an authentication event and continue until it is terminated. The session MAY be terminated for any number of reasons, including but not limited to an inactivity timeout or an explicit logout event. The session MAY be extended through a reauthentication event (described in Sec. 5.2) in which the subscriber repeats some of the initial authentication process or performs a full authentication, thereby reestablishing the authenticated session.
Session management is preferable to the continual presentation of credentials, as the poor usability of continual presentation often creates incentives for workarounds (e.g., caching activation factors), thereby negating authentication intent and obscuring the freshness of the authentication event.
A session occurs between the software (i.e., the session subject) that a subscriber is running (e.g., browser, application, or operating system) and the RP or CSP that the subscriber is accessing (i.e., the session host). A session secret SHALL be shared between the subscriber’s software and the accessed service. This secret binds the two ends of the session and allows the subscriber to continue using the service over time. The secret SHALL be presented directly by the subscriber’s software, or possession of the secret SHALL be proven using a cryptographic mechanism.
The continuity of authenticated sessions SHALL be based upon the possession of a session secret that is issued by the verifier at the time of authentication and optionally refreshed during the session. The nature of a session depends on the application, such as:
Session secrets SHOULD NOT be persistent (i.e., retained across a restart of the associated application or a reboot of the host device) because they are tied to specific sessions that a restart or reboot would end. Cookies and similar “remember my browser” features SHALL NOT be used instead of authentication except as provided for reauthentication at AAL2 in Sec. 2.2.3 when the inactivity limit has been exceeded but the time limit has not.
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 that triggered its creation. A session MAY be considered at a lower AAL than the authentication event but SHALL NOT be considered at a higher AAL than the authentication event.
The secrets used for session binding SHALL meet all of the following requirements:
In addition, secrets used for session binding SHOULD be erased on the subscriber endpoint when they log out or when the secret is deemed to have expired. They SHOULD NOT be placed in insecure locations (e.g., HTML5 Local Storage) due to the potential exposure of local storage to cross-site scripting (XSS) attacks.
Following authentication, authenticated sessions SHALL NOT fall back to an insecure transport (e.g., from https to http).
POST/PUT content SHALL contain a session identifier that the RP SHALL verify to protect against cross-site request forgery.
Several mechanisms exist for managing a session over time. The following sections give different examples, additional requirements, and considerations for each example technology. Additional informative guidance is available in the OWASP Session Management Cheat Sheet [OWASP-session].
Sessions SHOULD provide a readily accessible mechanism for subscribers to terminate (i.e., log off) their session when their interaction is complete. Session logoff gives the subscriber additional confidence and control over the security of their session, particularly in situations where the endpoint might be accessible to others.
Browser cookies are the predominant mechanism by which a session is created and tracked when a subscriber accesses a service. Cookies are not authenticators but are suitable as short-term secrets for the duration of a session.
Cookies used for session maintenance:
An access token (e.g., OAuth [RFC6749]) is used to allow an application to access a set of services on a subscriber’s behalf following an authentication event. The RP SHALL NOT interpret the presence of an OAuth access token as an indicator of the subscriber’s presence in the absence of other signals. The OAuth access token and any associated refresh tokens could be valid long after the authentication session has ended and the subscriber has left the application.
Periodic reauthentication of sessions SHALL be performed to confirm the subscriber’s continued presence at an authenticated session (i.e., that the subscriber has not walked away without logging out).
Session management uses two types of timeouts. An overall timeout limits the duration of an authenticated session to a specific period following authentication or a previous reauthentication. An inactivity timeout terminates a session without activity from the subscriber for a specific period. For both types of timeouts, the RP MAY alert the subscriber that the session is about to be terminated and allow the subscriber to make the session active or reauthenticate as appropriate before the session expires. When either timeout expires, the session SHALL be terminated. Session activity SHALL reset the inactivity timeout, and successful reauthentication during a session SHALL reset both timeouts.
The overall and inactivity timeout expiration limits depend on several factors, including the AAL of the session, the environment in which the session is conducted (e.g., whether the subscriber is in a restricted area), the type of endpoint being used (e.g., mobile application or web-based), whether the endpoint is a managed device1, and the nature of the application itself. Agencies SHALL establish and document the inactivity and overall time limits being enforced in a system security plan such as that described in [SP800-39].
Detailed requirements for each AAL are given in Sec. 2.1.3, Sec. 2.2.3, and Sec. 2.3.3.
Special considerations apply to session management and reauthentication when using a federation protocol and IdP to authenticate at the RP, as described in [SP800-63C], special considerations apply to session management and reauthentication. The federation protocol communicates an authentication event at the IdP to the RP using an assertion, and the RP then begins an authenticated session based on the successful validation of this assertion. Since the IdP and RP manage sessions separately from each other and the federation protocol does not connect the session management between the IdP and RP, the termination of the subscriber’s sessions at an IdP and an RP are independent of each other. Likewise, the subscriber’s sessions at multiple different RPs are established and terminated independently of each other.
Consequently, when an RP session expires and the RP requires reauthentication, it is possible that the session at the IdP has not expired and that a new assertion could be generated from this session at the IdP without explicitly reauthenticating the subscriber. The IdP can communicate the time and details of the authentication event to the RP, but it is up to the RP to determine whether the reauthentication requirements have been met. Section 4.7 of [SP800-63C] provides additional details and requirements for session management within a federation context.
\clearpage
Session monitoring (sometimes called continuous authentication) is the ongoing evaluation of session characteristics to detect possible fraud during a session.
Session monitoring MAY be performed by the RP, in coordination with the CSP/verifier, as a risk reduction measure. When potential fraud is detected during a session, the RP SHOULD take action in conjunction with the CSP/verifier, such as to reauthenticate, terminate the session, or notify appropriate support personnel. Session characteristics that MAY be evaluated include:
Most of these characteristics have privacy implications. Collection, storage of expected subscriber characteristics, and processing of session characteristics SHALL be included in the privacy risk assessment described in Sec. 7.
Managed devices include personal computers, laptops, mobile devices, virtual machines, or infrastructure components that are equipped with a management agent that allows information technology staff to discover, maintain, and control them. ↩