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.

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:

• OAuth 2.0 and OpenID Connect (OIDC) overview
• SAML 2.0 (conceptual information)

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 tickets can be sent to Airlock IAM in different ways:

• Configuration in the Loginapp REST API: SSO ticket authentication in the Loginapp REST API
• Configuration in the Loginapp UI: SSO tickets in the Loginapp UI
• Configuration in One-shot authentication (Loginapp): One-Shot Configuration
• Configuration in the Adminapp: Adminapp >> Administrators >> SSO Settings