OAuth, OIDC and SAML: Where Federated Trust Breaks
redirect_uri validation, PKCE, OIDC discovery, SAML signature wrapping and metadata, dynamic client registration and device-flow phishing.
Federated identity moves the authentication decision to another party and then re-imports the answer. Every note below is about a step in that import that trusts the wrong field.
OAuth redirect_uri Validation
An authorization code has limited value if it only reaches the correct client. That is why redirect_uri is one of OAuth’s most important boundaries. The Authorization Server compares the presented redirect URI with registered client URIs. RFC 9700 recommends exact matching except for specific cases. Wildcards, prefix matching and open redirects on trusted domains may move the code or token toward another destination. I compare the authorization request and callback, then test scheme, host, port, path, encoding and internal redirectors. An accepted URI alone is not enough. The pentest needs to show that the authorization response can reach an attacker-controlled context.
1
GET /authorize?client_id=abc&redirect_uri=https%3A%2F%2Fapp.example%2Fcallback&response_type=code HTTP/1.1
PKCE Internals
PKCE makes a stolen authorization code far less useful when the attacker does not possess the verifier from that transaction. The client generates a code_verifier and sends a derived code_challenge in the authorization request. During token exchange it presents the original verifier. S256 avoids exposing the verifier and is the recommended method. plain exists for historical compatibility and should be avoided. I confirm PKCE presence, method, per-transaction binding and rejection of missing or incorrect verifiers. PKCE does not replace state, issuer validation or secure redirect URI handling. Each mechanism binds different parts of the flow.
1
2
code_verifier=$(openssl rand -base64 48 | tr -d '=+/')
printf '%s' "$code_verifier" | openssl dgst -sha256 -binary | openssl base64 -A | tr '+/' '-_' | tr -d '='
OIDC Discovery
A .well-known document can decide which issuer, JWKS and endpoints a client treats as authoritative. OpenID Connect Discovery publishes issuer, authorization endpoint, token endpoint and jwks_uri. Dynamic clients use this metadata to configure trust. Issuer confusion, attacker-controlled discovery and wrong-origin JWKS may push the client into validating tokens in the wrong context. I capture the discovery document, confirm HTTPS, exact issuer, jwks_uri and whether endpoints belong to the same trust relationship. A valid JWT signature does not fix the wrong issuer. The client must validate iss, aud, nonce and key source for the expected provider.
1
curl -s https://idp.example/.well-known/openid-configuration | jq .
SAML
SAML becomes much easier when you separate the system asserting identity from the system deciding to accept that assertion. The IdP issues assertions. The SP consumes those assertions and creates a local session. Entity IDs, ACS URLs, certificates and audience define the trust relationship. Responses and Assertions may be signed at different levels. The SP needs to validate signature, issuer, audience, conditions and destination correctly. I capture the full login flow, decode the XML and document exactly which element is signed before modifying any field. Base64 and XML encryption do not replace signatures. A readable assertion may still have strong integrity when signature validation is correct.
1
2
3
4
python3 - <<'PY2'
import base64
print(base64.b64decode(open('saml.txt','rb').read()).decode())
PY2
SAML Signature Wrapping
Signature wrapping appears when the verifier validates one signed element while the application uses another element to decide who the user is. XML Signature references elements by ID. Wrapping inserts or moves elements to separate the node being validated from the node consumed by business logic. A library may report a valid signature while application code reads the first Assertion or another unsafe path. I identify Reference URI, IDs, the element consumed by the SP and test structural duplication only in a lab. Canonicalization, schema validation and exact selection of the signed element matter as much as the signature cryptography.
Inspect the XML Signature Reference URI and the exact Assertion the application consumes, and keep structural tests inside a dedicated SAML lab.
OAuth Device Authorization Grant
Device Flow exists for devices without a convenient browser. The user authenticates elsewhere and a short code links the two sessions. The device receives a device_code and user_code, then polls the token endpoint while the user approves at a verification URI. Phishing may try to convince a victim to enter an attacker-generated user_code. The consent UX should make client and action clear. I test expiry, polling interval, client binding and what the approval page displays before consent. A short user code is expected. Security depends on adequate entropy, short lifetime, rate limiting and consent that identifies the client.
1
2
3
4
5
POST /oauth/device/code HTTP/1.1
Host: idp.example
Content-Type: application/x-www-form-urlencoded
client_id=lab-client
SAML Metadata and Trust Misconfigurations
SAML metadata distributes entity IDs, endpoints and certificates. If an SP imports too much trust, configuration errors can matter as much as code bugs. Metadata describes IdPSSODescriptor, SPSSODescriptor, keys and endpoints. Federation automation may update certificates and entities. Trust in multiple IdPs, stale certificates and entity-ID confusion may send assertions into the wrong relationship. I compare configured metadata with runtime assertions, issuer values and the signing key actually used. Accepting remote metadata without authentication or change control creates an identity supply chain. Certificate rotation needs planning.
1
xmllint --format metadata.xml | sed -n '1,160p'
OAuth Dynamic Client Registration
Dynamic registration is a legitimate feature. Risk appears when redirect URIs, software metadata and new-client trust are not validated for the environment. RFC 7591 allows clients to register programmatically with redirect URIs and metadata. Registration access tokens may control later changes. Open registration may be expected in a public ecosystem. In a closed environment it may create arbitrary clients and expand phishing or redirect abuse. I identify the registration endpoint, authentication requirement and redirect-URI validation using a lab domain. Being able to register a client is not account takeover by itself. Impact depends on scopes and trust the Authorization Server grants new clients.
1
2
3
4
POST /register HTTP/1.1
Content-Type: application/json
{"redirect_uris":["https://lab.example/callback"],"client_name":"lab"}