OAuth 2.0 and SSO Attacks

OAuth 2.0 is an authorization framework that enables third-party applications to obtain limited access to a user's resources without exposing the user's credentials. Defined in RFC 6749, it separates the role of the resource owner (user) from the client (application) and the authorization server. This separation is critical for security: the client never sees the user's password, and access can be scoped and revoked independently.

The core flow involves four roles: - Resource Owner: The user who owns the data. - Client: The application requesting access. - Authorization Server: Issues tokens after authenticating the resource owner. - Resource Server: Hosts the protected resources and validates tokens.

The most common flow is the Authorization Code Grant, which works as follows: 1. The client redirects the user to the authorization server with parameters: response_type=code, client_id, redirect_uri, scope, and state. 2. The user authenticates and consents to the requested scopes. 3. The authorization server redirects back to the client with an authorization code in the query string. 4. The client exchanges this code for an access token by making a POST request to the token endpoint with grant_type=authorization_code, code, redirect_uri, and client_secret. 5. The authorization server returns an access token (and optionally a refresh token). 6. The client uses the access token to request resources from the resource server.

While OAuth 2.0 is not a command-line protocol, penetration testers often use tools like Burp Suite, Postman, or custom scripts to test implementations. For example, testing an OAuth endpoint with curl:

# Step 1: Get authorization code (user interaction required, simulate via browser)
# Step 2: Exchange code for token
curl -X POST https://auth.example.com/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code&code=abc123&redirect_uri=https://client.example.com/callback&client_id=myclient&client_secret=secret"

Response:

{
  "access_token": "eyJhbGciOiJSUzI1NiIs...",
  "token_type": "Bearer",
  "expires_in": 3600,
  "refresh_token": "def456",
  "scope": "read write"
}

#### Authorization Code Interception If an attacker can intercept the authorization code (e.g., via an insecure redirect URI or a man-in-the-middle attack), they can exchange it for an access token. The redirect_uri must be strictly validated; any open redirect vulnerability can be exploited.

#### CSRF on Authorization Code Flow Without the state parameter, an attacker can trick a user into authorizing a malicious client. The state parameter binds the request to the user's session.

#### Token Theft and Replay If an access token is stolen (e.g., via XSS, insecure storage, or network sniffing), the attacker can use it until it expires. Using HTTPS is mandatory.

#### Implicit Grant Weaknesses The implicit grant returns the access token directly in the URL fragment, increasing exposure. It is deprecated in OAuth 2.1 and should not be used.

#### Client Secret Leakage In public clients (e.g., mobile apps, SPAs), client secrets cannot be stored securely. The PKCE (Proof Key for Code Exchange) extension mitigates this by replacing the secret with a dynamically generated code verifier.

Single Sign-On (SSO) allows users to authenticate once and access multiple applications. Common SSO implementations include OAuth 2.0 + OIDC, SAML, and Kerberos.

#### SAML Attacks - XML Signature Wrapping: Manipulating the SAML assertion while keeping the signature valid. - Replay Attacks: Reusing a valid SAML response within its validity window. - Identity Provider Confusion: Tricking the service provider into accepting an assertion from a malicious IdP.

#### OIDC Attacks - Token Substitution: Swapping an ID token or access token from one user to another. - Cross-Site Request Forgery (CSRF): Without the nonce parameter in the ID token, an attacker can reuse an authentication response. - Unverified User Info: If the client does not validate the ID token's signature and issuer, an attacker can forge tokens.

#### Kerberos Attacks - Pass-the-Ticket: Stealing a Kerberos ticket and using it to authenticate as the victim. - Golden Ticket: Forging a Ticket Granting Ticket (TGT) with a compromised KRBTGT hash. - Silver Ticket: Forging a service ticket for a specific service.

OAuth 2.1 (RFC 6749 bis) consolidates best practices and deprecates implicit grant and resource owner password credentials grant. PKCE is now required for all public clients. PKCE works as follows:

This prevents interception of the authorization code from being exchanged for a token, because the attacker does not know the code_verifier.

A company uses Salesforce as its CRM and wants to integrate with a third-party analytics tool. The analytics tool needs read access to Salesforce data. Using OAuth 2.0, the company's admin authenticates to Salesforce (authorization server) and grants the analytics tool (client) access with the scope api. The tool receives an access token valid for 1 hour and a refresh token valid for 30 days. This setup ensures that the analytics tool never stores Salesforce credentials. If the integration is decommissioned, the admin can revoke the tokens from Salesforce. A common misconfiguration is using too broad a scope (e.g., full instead of api), giving the third-party tool excessive permissions.

A large enterprise adopts Azure AD as its identity provider (IdP) for all internal applications. Employees log in once and access email (Exchange Online), file storage (SharePoint), and custom HR apps. Each application is an OIDC client that redirects to Azure AD for authentication. The ID token contains user claims like name, email, and employeeid. The access token is used to call Microsoft Graph API. A critical security consideration is token lifetime: if access tokens have a long lifetime (e.g., 24 hours), a stolen token can be used for a full day. The enterprise should configure token lifetime policies (e.g., 1 hour) and enforce device compliance before issuing tokens.

A university uses Shibboleth as its SAML IdP. Students log in once to access the learning management system (LMS), library resources, and email. The LMS (service provider) receives a SAML assertion containing the student's unique ID and attributes like role (e.g., 'student' or 'faculty'). A common attack is XML signature wrapping: the attacker modifies the assertion's content (e.g., changes the user ID) while keeping the signature valid by exploiting flaws in the XML parser. Another issue is replay: if the assertion's NotOnOrAfter condition is not validated, an attacker can reuse a captured assertion. The university must enforce short assertion lifetimes (e.g., 5 minutes) and use signed assertions with proper XML canonicalization.