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.

SSO (single-sign-on) tickets are bearer tokens to re-authenticate a user with a second factor. Re-authentication is performed during high-risk transactions to verify that an authorized user indeed executes a requested action. With SSO tickets, consenting to a transaction's details is impossible.

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.

• When 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 and 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.

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. To obtain the SSO ticket, the user must re-authenticate.

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 – to ensure that any existing authentication state has been removed before the authorization code grant starts the authentication process.

This 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 and 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
1. start the authorization code flow directly, forcing the user to enter both authentication factors one after the other.
2. the client can refresh the access token, retrieve an SSO ticket and 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 has an access token containing 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 the reuse of the token.

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

• Internal links:
• For an example configuration, see Forced user re-authenticate.
• Single sign-on (SSO) ticket authentication