SSO tickets
13.3.1.7. AS-centric AS - SSO tickets

This section describes SSO tickets and what they are used for. It provides recommendations for a secure implementation of SSO tickets. A detailed example shows how SSO tickets are used within a re-authentication process.

Purpose of SSO tickets

SSO (single-sign on) tickets are bearer tokens used to re-authenticate a user with a second factor. Re-authentication is performed during high-risk transactions in order to verify that a requested action is indeed executed by an authorized user. With SSO tickets, consenting to details of a transaction is not possible.

Security Recommendations for SSO tickets

SSO tickets provide a powerful mechanism for replacing user interactions in an authentication flow. This increases the risk of attacks aiming at the elevation of rights. Therefore, special care should be taken to avoid the abuse of SSO tickets!

  • Recommendations for securely using SSO tickets:
  • Don't reuse existing SSO tickets (one-time use only).
  • Don't use the same SSO ticket for multiple use cases, e.g. by reusing Airlock IAM plugins.
  • Assign a very short ticket lifetime.
  • Sign the tickets.
  • Encrypt the tickets.
  • Treat SSO tickets as a single authentication factor. Hence, they should never be used for identity propagation to applications requiring a strong authentication result.

Obtaining an SSO ticket

When accessing a resource's endpoint, the client must provide an access token as a bearer token. If the resource server requires an SSO ticket, the access token must be exchanged for an SSO ticket. In order to obtain the SSO ticket, the user must re-authenticate.

Using an SSO ticket

An SSO ticket must be submitted as a login_hint in an authorization code flow. A request starting an authorization code flow with an SSO ticket must provide these parameters:

  • login_hint: SSO ticket, to be used to authenticate the user
  • acr_values: to request a minimum authentication quality
  • prompt=login: this makes sure that any existing authentication state is removed before the authorization code grant starts the authentication process.

Example - a re-authentication process in detail

The example demonstrates a complete re-authentication process involving SSO tickets. The user with a fully authenticated and authorized session is forced to re-authenticate with a second factor. The back-end resource server is in control over the forced re-authentication of the user. This is achieved using the OIDC authorization code flow combined with an OIDC SSO ticket. For security reasons, two different SSO tickets are used:

  • OIDC SSO ticket: It is created by the resource server and consumed at the start of the authorization code flow. Its scope is limited to the authorization server. Therefore, it can't be used in an authentication flow.
  • AuthN SSO ticket: It is issued by the authorization server and consumed at the beginning of the authentication flow.
  • Overview of the re-authentication process using SSO tickets:
  • The back-end resource uses session management to revoke the access token with scope "one-time scope".
  • This forces the client to obtain a new access token by performing a token refresh.
  • The scope "one-time scope" is removed from the access token upon token refresh.
  • At this point, the client can either
    • start the authorization code flow directly and thereby force the user to enter both authentication factors one after the other.
    • or the client can refresh the access token, retrieve an SSO ticket and now start an authorization code flow with prompt, acr_values, and SSO ticket. This will allow the user to authenticate with only the 2nd factor.
  • At the end of the authorization code flow, the client now has an access token that contains the "one-time scope" and presents this to the back-end resource.
  • The back-end resource validates this access token.
  • The back-end resource immediately revokes the access token using session management (to prevent reuse of the token).

The sequence diagram below shows the involved steps and the messages between the different entities in detail.

RE-Auth_Flow

Further information and links