IdP, SAML, JWT, OAuth, and OIDC

Modern SSO is a trust system. One system authenticates the user, another system consumes a signed assertion or token, and an application decides what the user can do. Most incidents come from mixing up authentication, authorization, token type, audience, redirect endpoint, or trust metadata.

Command Examples

curl -sS https://<idp-domain>/.well-known/openid-configuration
curl -sS https://<idp-domain>/.well-known/jwks.json
openssl x509 -in <saml-signing-cert.pem> -noout -subject -issuer -dates -fingerprint -sha256
python3 -m json.tool <token-payload.json>

Example output and meaning:

Authentication vs Authorization

OAuth is primarily an authorization framework. OpenID Connect adds an identity layer on top of OAuth 2.0. SAML is a federation protocol commonly used for browser SSO. JWT is a token format, not an authorization framework by itself.

Identity Provider

An Identity Provider (IdP) authenticates a principal and issues identity data to another system. That system might be a SAML Service Provider, an OIDC Relying Party, or a custom application consuming tokens.

IdP responsibilities commonly include:

• user authentication and MFA policy,
• session lifetime and reauthentication rules,
• group or attribute release,
• signing keys and certificate rotation,
• application registration,
• redirect URI or ACS URL allow lists,
• audit logs for authentication and token issuance.

An IdP does not automatically grant application permissions. Applications still need their own authorization model, because the IdP may only prove identity and release attributes.

Sessions, Cookies, and Tokens

Browser SSO usually has more than one credential at the same time:

Logging out of one layer may not log out of the others. An application can clear its session cookie while the IdP session still silently authenticates the next login request. Conversely, an API access token may remain valid until expiry even after the browser session ends unless revocation or introspection is enforced.

Session and token design choices:

• keep access tokens short lived,
• rotate refresh tokens when the platform supports it,
• store browser tokens where JavaScript exposure is minimized,
• mark cookies Secure, HttpOnly, and SameSite where possible,
• define what “logout” means for app session, IdP session, and API tokens,
• avoid putting bearer tokens in URLs, logs, traces, or support screenshots.

SAML

SAML 2.0 is XML-based federation. The main browser SSO roles are:

Important SAML objects:

• Assertion: signed statement about authentication, subject, attributes, and conditions.
• Response: protocol message that carries the assertion to the SP.
• AuthnRequest: SP request asking the IdP to authenticate the user.
• ACS URL: Assertion Consumer Service endpoint where the IdP posts the response.
• Entity ID: stable identifier for the IdP or SP in metadata.
• NameID: subject identifier format and value.
• Metadata: XML describing endpoints, signing certificates, identifiers, and supported bindings.

SAML failures are often metadata failures. If the SP entity ID, ACS URL, signing certificate, clock, or NameID format does not match what the IdP expects, login can fail before the application sees a user.

SAML Browser SSO Flow

sequenceDiagram
  participant Browser
  participant SP as Service Provider
  participant IdP as Identity Provider

  Browser->>SP: Request protected page
  SP-->>Browser: Redirect with AuthnRequest
  Browser->>IdP: Send AuthnRequest
  IdP->>Browser: Authenticate user and create SAML Response
  Browser->>SP: POST Response to ACS URL
  SP->>SP: Validate signature, issuer, audience, conditions, destination, NameID
  SP-->>Browser: Create app session cookie

SAML validation evidence:

OAuth 2.0

OAuth 2.0 defines roles:

The authorization code flow with PKCE is the common default for browser-based and native applications. The client sends the user to the authorization server, receives an authorization code on the redirect URI, exchanges that code for tokens, and then presents an access token to the API.

OAuth/OIDC Authorization Code with PKCE

sequenceDiagram
  participant Browser
  participant Client as Client App
  participant AS as Authorization Server / OP
  participant API as Resource Server

  Client->>Client: Generate code_verifier and code_challenge
  Browser->>AS: Authorize request with client_id, redirect_uri, scope, state, nonce, code_challenge
  AS->>Browser: Authenticate and consent
  AS-->>Browser: Redirect with code and state
  Browser->>Client: Callback to registered redirect URI
  Client->>AS: Token request with code and code_verifier
  AS-->>Client: ID token, access token, optional refresh token
  Client->>Client: Validate ID token for login
  Client->>API: Present access token for API call
  API->>API: Validate access token issuer, audience, signature, expiry, scopes

PKCE binds the authorization code to the client that started the flow. state protects request correlation and CSRF. nonce binds the OIDC ID token to the authentication request. These fields solve different problems and should not be treated as interchangeable.

Operational details:

• Redirect URIs must be exact and pre-registered.
• Scopes describe requested access, but APIs still need local enforcement.
• Access tokens are for resource servers, not for proving login to the client.
• Refresh tokens need careful storage, rotation, revocation, and theft detection.
• A refresh token is a high-value credential because it can mint new access tokens after the original access token expires.
• A Bearer token can be used by whoever possesses it, so storage, transport, logs, and browser exposure matter.
• Client credentials flow is for machine-to-machine access, not human login.
• New systems should avoid implicit flow and resource owner password credentials unless a specific legacy constraint forces them.

OpenID Connect

OpenID Connect (OIDC) adds authentication and identity data to OAuth 2.0. The OpenID Provider issues an ID token to the client. The client validates it and uses it to establish who authenticated.

Important OIDC pieces:

• ID token: JWT carrying identity claims for the client.
• Access token: token for an API or resource server.
• UserInfo endpoint: optional way to fetch additional user claims.
• Discovery document: .well-known/openid-configuration metadata for endpoints and supported settings.
• JWKS: JSON Web Key Set used to publish public keys for token verification.
• nonce: binds an authentication response to a client request and helps prevent replay.

Do not send an ID token to an API as proof of API authorization unless that API is explicitly designed to accept that token and audience. Most APIs should validate access tokens.

JWT

JSON Web Token (JWT) is a compact claims format. A signed JWT is commonly a JWS with three base64url parts:

Common claims:

JWT validation checklist:

1. Parse the token without trusting the claims yet.
2. Select the verification key from trusted issuer metadata, often by kid.
3. Allow only expected algorithms; do not accept arbitrary alg values from the token.
4. Verify the signature.
5. Verify iss, aud, exp, nbf, and acceptable clock skew.
6. Enforce scopes, roles, groups, or entitlements locally.
7. Decide revocation behavior for long-lived sessions or high-risk actions.

Decoding a JWT is not validation. Anyone can base64url-decode the header and payload.

JWT Validation Decision Tree

flowchart TB
  Token[Received JWT] --> Parse[Parse header and claims without trusting them]
  Parse --> Issuer{Issuer is configured and trusted?}
  Issuer -->|No| Reject1[Reject]
  Issuer -->|Yes| Metadata[Load trusted metadata / JWKS]
  Metadata --> Alg{Algorithm allowed for this issuer?}
  Alg -->|No| Reject2[Reject]
  Alg -->|Yes| Key[Select key by kid, issuer, and algorithm]
  Key --> Sig{Signature verifies?}
  Sig -->|No| Reject3[Reject]
  Sig -->|Yes| Claims{iss, aud, exp, nbf, tenant, nonce as required?}
  Claims -->|No| Reject4[Reject]
  Claims -->|Yes| Policy[Apply scopes, roles, groups, and local authorization]
  Policy --> Decision[Allow or deny action]

Common token confusion:

Key Rotation and JWKS

OIDC and JWT systems often publish verification keys through JWKS. Rotation is normal and should not be an incident.

Safe validation behavior:

• trust keys only from configured issuers,
• cache JWKS for a bounded time,
• use kid to select a candidate key but still verify issuer and algorithm policy,
• handle overlapping old and new keys during rotation,
• fail closed if the issuer metadata cannot be trusted,
• alert on unknown kid spikes because they may indicate rotation, config drift, or forged tokens.

SAML has the same operational problem with signing certificates in metadata. Certificate rollover should be planned with overlap so Service Providers can trust old and new signing material during the transition.

Session and Token Lifetime Timeline

sequenceDiagram
  participant User
  participant Browser
  participant IdP
  participant App
  participant API

  User->>IdP: Authenticate
  IdP-->>Browser: IdP session cookie
  IdP-->>App: ID token / assertion
  App-->>Browser: Application session cookie
  App->>API: Access token until expiry
  App->>IdP: Refresh token rotation for new access token
  User->>App: Logout
  App-->>Browser: Clears app session
  Note over Browser,IdP: IdP session and API tokens may still exist unless revoked or expired

Logout and incident-response questions:

Which One Do I Use?

Common Mistakes

• Calling OAuth “login” without OIDC and then treating an access token as identity.
• Accepting a JWT after decoding it but before verifying signature and claims.
• Reusing one token audience across many APIs.
• Storing long-lived bearer tokens where browser JavaScript, logs, or support tools can expose them.
• Missing SAML certificate rollover and breaking every SP at once.
• Confusing SAML IdP-initiated convenience with complete request correlation.
• Trusting groups or roles from an IdP without checking whether the application expected those exact claim names and formats.
• Ignoring clock sync; SAML and JWT validation are time-sensitive.

Debugging Flow

1. Identify the protocol: SAML, OAuth, OIDC, or a custom JWT flow.
2. Identify the failing hop: redirect, login, assertion/token issuance, token exchange, callback, session creation, or API call.
3. Check issuer, audience, redirect URI or ACS URL, signing key, and time validity.
4. Separate ID tokens from access tokens.
5. For SAML, compare IdP and SP metadata: entity ID, ACS URL, bindings, NameID format, and signing certificate.
6. For OIDC/OAuth, inspect discovery metadata, JWKS, client registration, scopes, response type, grant type, and PKCE settings.
7. Check local application authorization after token validation succeeds.

Study Cards

References

• OAuth 2.0 Authorization Framework, RFC 6749
• OAuth 2.0 Bearer Token Usage, RFC 6750
• JSON Web Token, RFC 7519
• JSON Web Signature, RFC 7515
• JSON Web Key, RFC 7517
• OpenID Connect Core 1.0
• OASIS SAML 2.0 Technical Overview