Cloud IAM and Identity Architecture

<md:EntityDescriptor entityID="https://idp.example.com">
  <md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    <md:KeyDescriptor use="signing">
      <ds:KeyInfo><ds:X509Data><ds:X509Certificate>...</ds:X509Certificate></ds:X509Data></ds:KeyInfo>
    </md:KeyDescriptor>
    <md:SingleSignOnService Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect" Location="https://idp.example.com/sso"/>
  </md:IDPSSODescriptor>
</md:EntityDescriptor>

OAuth 2.0 Authorization Code Flow (cURL):

# Step 1: Get authorization code (user interaction via browser)
# Redirect user to:
https://idp.example.com/authorize?response_type=code&client_id=myclient&redirect_uri=https://sp.example.com/callback&scope=openid%20profile&state=123
# Step 2: Exchange code for tokens
curl -X POST https://idp.example.com/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=authorization_code&code=AUTH_CODE&redirect_uri=https://sp.example.com/callback&client_id=myclient&client_secret=mysecret"
# Response includes access_token, id_token, refresh_token

JWT Token Decoded:

{
  "iss": "https://idp.example.com",
  "sub": "user123",
  "aud": "https://sp.example.com",
  "exp": 1700000000,
  "iat": 1699996400,
  "nonce": "abc123"
}

AWS IAM Policy Example:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my-bucket/*",
      "Condition": {
        "StringEquals": {
          "aws:RequestedRegion": "us-east-1"
        }
      }
    }
  ]
}

Scenario 1: OAuth Token Theft in a Cloud SaaS Application A company uses a third-party project management tool (SP) that integrates with their corporate IdP via OAuth 2.0. An attacker exploits a cross-site scripting (XSS) vulnerability in the tool to steal users' access tokens stored in the browser's local storage. The attacker then uses the tokens to access the tool's API and exfiltrate project data. The SOC analyst sees unusual API calls from IPs not associated with the company, and the IdP logs show token usage from unknown locations. The correct response is to revoke all tokens for affected users, force re-authentication, and implement token binding (e.g., using mTLS) to tie tokens to the client's certificate. A common mistake is to only reset passwords, which does not invalidate existing tokens.

Scenario 2: SAML Assertion Replay Attack An attacker captures a SAML assertion by sniffing unencrypted traffic on a public Wi-Fi network. The assertion is valid for 30 minutes. The attacker replays the assertion to the SP's ACS endpoint, gaining access as the user. The SP logs show two identical authentication requests with the same assertion ID within minutes. The SOC analyst detects this by correlating timestamps and assertion IDs. The correct response is to implement assertion cache validation (reject duplicate assertion IDs), use short assertion lifetimes (e.g., 5 minutes), and enforce HTTPS. A common mistake is to assume that signing the assertion prevents replay; but signing does not prevent replay—it only prevents tampering.

Scenario 3: IdP Confusion in OIDC A company deploys a custom web application that uses OIDC for SSO. The application is configured to trust any IdP that provides a valid ID token. An attacker registers a malicious IdP and tricks a user into logging in via that IdP (e.g., via a phishing email). The attacker's IdP issues an ID token with the user's email claim set to a privileged user's email. The application trusts the token and grants the attacker elevated privileges. The SOC analyst sees a login from an unrecognized IdP issuer in the logs. The correct response is to whitelist the company's IdP issuer in the application and validate the iss claim. A common mistake is to rely on the email claim alone for authorization without verifying the issuer.