| 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. |
| 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. |
| 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. |
| Airlock IAM does not allow SSO tickets to be used more than once. To achieve this, Airlock IAM stores the last 100000 valid SSO tickets in memory to verify if a ticket has been used before. 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. |
| If possible, combine SSO ticket authentication with a 2nd factor. |