Single sign-on (SSO) ticket authentication

End-users can be authenticated by presenting so-called SSO tickets.

In Airlock IAM, SSO tickets are statements about an authenticated end-user issued by another system.

They contain the name or id of the authenticated end-user and optionally roles and other user attributes. SSO tickets are usually digitally signed and have an expiry date. Although Airlock IAM supports different formats, JWT is the most commonly used and recommended way to encode an SSO ticket.

In other contexts, SSO tickets are also called bearer tokens.

Usage and properties of SSO tickets

With SSO tickets, verified end-user information can be easily transported from one to another system - even across domain boundaries. SSO tickets, therefore, offer a simple way to implement (cross-domain) single sign-on.

Because of the supported standardized JWT format, SSO tickets are also used to connect 3rd party systems to Airlock IAM (or vice versa).

SSO tickets are a very simple and flexible way of implementing single sign-on but they do not provide the same features and security as other standard protocols supported by Airlock IAM. Especially, SSO tickets offer no way of single logout or token revocation.

Before using SSO tickets, consider if one of the following alternatives suits your requirements better:

Security considerations and recommendations

In case an SSO ticket is stolen, the attacker may use the SSO ticket to create a fully authenticated and authorized session in the name of the end-user.

For secure usage of SSO tickets, consider the following:

Authenticity

The receiver of the SSO ticket must verify their authenticity, i.e., that it has been issued by a trusted entity.

This is typically achieved by using digital signatures as supported by JWT. Make sure that the configured public key used to verify the signature has been verified to belong to the trusted entity.

Secrecy

If the SSO ticket contains sensitive information and if it is transported over a non-confidential channel, the ticket must be encrypted.

This is typically achieved by using encryption as supported by JWT.

Validity

SSO tickets must contain an expiry date (not valid after). Within the validity period, an SSO ticket cannot be revoked.

Thus, SSO tickets should be valid for only a very limited amount of time. Depending on the use-case, this may be only a few seconds. Make sure that the clocks of the sending and the receiving entity are synchronized.

Replay prevention

Airlock IAM does not allow SSO tickets to be used more than once.

To achieve this, Airlock IAM stores successfully validated SSO tickets in memory or alternatively on the database. It is strongly recommended to store the tickets on the database to guarantee replay prevention even across multiple IAM instances.

To uniquely identify an SSO ticket, Airlock IAM uses the JWT jti attribute (RFC 7523). Airlock IAM uses a hash over the entire ticket if no JWT jti value is provided or available.

Replay prevention is not available for tickets without an expiry date.

Replay prevention is not available in the one-shot authentication.

2nd factor

If possible, combine SSO ticket authentication with a 2nd factor.

SSO ticket transport

SSO tickets can be sent to Airlock IAM in different ways:

Type

Description

Supported in

URL parameter

The SSO ticket is sent to IAM in an HTTP GET parameter when accessing an application.

Example: .../application/access/appid?sso=eyJhbGciOiJI...

Example: .../check-login?Location=…&sso=eyJhbGciOiJI...

Note that the SSO ticket parameter may be sent together with a Location parameter but not as part of the Location.

Loginapp UI

Adminapp

HTTP Header

The SSO ticket is sent in an HTTP header (configurable) when accessing an application.

Example: X-Login-Token: eyJhbGciOiJI…

Loginapp REST API

One-Shot Authentication

HTTP Cookie

The SSO ticket is sent in an HTTP cookie (configurable) when accessing an application.

Example: Cookie: X-LOGIN=eyJhbGciOiJI…;

Loginapp REST API