SSO Bad Practices: Authentication Token Replay

Single Sign-On (SSO) messages that do not implement steps to prevent authentication token replay might be susceptible to impersonation attacks.

Single sign-on enables a service provider to use a single identity system across multiple applications without requiring that each application manage credential information separately. An identity provider verifies the user credentials and provides a token to the service provider to prove the user's validity. These tokens are the primary artifact the service provider uses to authenticate and authorize users into the service. These tokens are susceptible to replay attacks and can enable an attacker to impersonate a valid user and gain unauthorized access to the service. A network intruder with man-in-the-middle access or browser cache on a public kiosk could reveal this type of authentication token to malicious vectors. After attackers have access to a valid token, user credentials are not required, which could be secured with an additional two factor provision. Security Assertion Markup Language (SAML) tokens are a popular example of SSO tokens. A service provider can take several measures to prevent replay attacks for SAML tokens. These include setting a short token validity period and assigning a unique ID to each token request and response.