Skip to content

Sessions and Timeouts

Jump to bottom Edit New page
Hans Zandbelt edited this page Dec 19, 2022 · 11 revisions

When deploying mod_auth_openidc for user authentication using OpenID Connect there are different sessions and timeouts at play at the same time. This page aims to describe those parameters and their relation.

Sessions

After successful authentication there are 2 (or 3) sessions created.

1. mod_auth_openidc session

The module creates a session for the user that is tracked by a cookie. This session holds information about the user, the OpenID Connect tokens that have been created, and session timeouts. This information can be stored client side or server side. The session will expire after:

For more information on how to configure parameters for this session, see: https://github.com/zmartzone/mod_auth_openidc/wiki/Session-management-settings

2. Provider Session

The authentication of the user is done at the OpenID Connect Provider. The Provider creates a Single Sign On session for the user, also tracked by a (Provider/SSO) cookie. This session (and its cookie) is independent from the session that mod_auth_openidc creates, and it has its own timeouts. This leads to a number of observations:

  • when the module's session expires, the user will be redirected to the Provider for authentication; at that point the Provider SSO session may stil be active and the user will just return to the module and a new mod_auth_openidc session is created without explicit authentication
  • when the Provider session expires, the module's session may still be valid and the user will be able to continue to use the application until mod_auth_openidc's session itself expires, the user is redirected to the Provider for authentication and explicit authentication is required because there's no active SSO session
  • a logout of mod_auth_openidc, a logout at the Provider, or a logout from one of the other applications connected to the Provider, will only result in the termination of all sessions when OpenID Connect Single Logout has been configured for all those applications

3. (optional) Application Session

When protecting a legacy application (e.g. running in a Tomcat container), that application may create its own session (e.g. tracked by a JSESSIONID cookie) once an authenticated request comes in. That session is independent from the (2) sessions mentioned above and may have its own timeouts. This leads to the following observations:

  • expiry of this session may result in a new session created for the same user, assuming the module's session is still active
  • expiry of the module's session will result in re-authentication at the Provider, even if the application session is still alive.

Timeouts

Apart from each of the sessions above having its own inactivity timeout and maximum duration, the following timeouts are also at play.

1. State Cookie Timeout

When the user is redirected to the Provider for authentication, a state cookie tracks the request to correlate it to the eventual authentication response; this cookie has its own timeout, representing the maximum time that the user can use to finish the authentication round trip, see: https://github.com/zmartzone/mod_auth_openidc/wiki/Cookies#state-cookie

2. ID token Timeout

After successful authentication at the Provider, an ID Token is generated that is sent back to the module. The ID Token contains a timeout that represents the maximum duration after which the token should no longer be accepted by the module. Note that the ID Token represents a user authentication event and is not a session in itself, nor is related to any session. (see also here)

3. Access Token Timeout

After successful authentication at the Provider, an Access Token is generated that is sent back and stored by the module. Note that the Access Token represents an access grant, it is not a session in itself, nor is related to any session. The access token is used for two purposes:

  • for calling the OpenID Connect UserInfo endpoint to obtain information about the authenticated user that is stored in the session; see here to (optionally) keep this information up to date during the time that the session lives
  • for passing it to a application that can use it to call (application specific) OAuth 2.0 protected APIs, see also here

The Access Token has an associated timeout after which calls using it will fail. If a refresh token was also returned by the Provider, one can optionally configure the module to obtain a new access token when needed, see https://github.com/zmartzone/mod_auth_openidc/wiki/Single-Page-Applications#refresh-access-token-ahead-of-expiry

4. Refresh Token Timeout

If a refresh token was returned by the Provider, it is stored as part of the module's session and may be used to obtain new access tokens until it expires, see previous bullet.

Session Timeout and Forms

The module's session timeout and behaviour can cause inconvenience for applications that present forms to the end user. Filling out a large form manually may take considerable time and during that time a potential session timeout will trigger an authentication redirect after which the form data is lost. The following options may be used as a workaround for that, all at the cost of decreasing security:

  1. increase OIDCSessionInactivityTimeout

    Set it to the maximum time that users have to complete the form; note that this is a global setting that applies to all pages and all forms.

  2. set OIDCPreservePost On

    This will aim to store the form data temporarily in the browser storage, redirect the user for authentication and then restore that data, see here ; be aware that sensitive data may be stored and left in the browser in case the user never actually finishes the authentication roundtrip

  3. keep the session alive on the Form page

    By sending HTTP GET (or XHR) requests to a protected endpoint (e.g. <OIDCRedirectURI>?info=json to also obtain the timeout settings) the inactivity time will be reset on each request, effectively extending the session, see e.g. here; note that this may lead to the session being kept alive forever (when the user stays on that page in a browser tab), or you'll have to implement a page timeout yourself, which would basically bring you back to the original problem (in this case with differentiated timeouts for different pages)

Single Page Applications

https://github.com/zmartzone/mod_auth_openidc/wiki/Single-Page-Applications

Add a custom footer
Add a custom sidebar
Clone this wiki locally