OAuth 2.0 & OIDC Flow Architect
Construct RFC 7636 PKCE authorization requests, generate cryptographic verifiers, decode OIDC ID tokens, and audit authorization vulnerabilities.
[A-Z, a-z, 0-9, -, ., _, ~]. The Code Challenge is BASE64URL-ENCODE(SHA256(ASCII(code_verifier))).
Live Challenge-Verifier Match Tester
Emulate authorization server validation: Paste any Verifier and Challenge to verify cryptographic equivalence.
OpenID Connect Token Response & ID Token Inspector
Inspect JWT header, claims, audience, expiry, and nonce validity in real-time.OIDC ID Token (JSON Web Token) Dissection
Claims Validation Audit
Interactive OAuth 2.0 Threat & Exploit Matrix
Inspect how real-world attackers exploit OAuth configurations and how RFC protocols mitigate each vulnerability.
The Threat: On mobile operating systems (iOS/Android) and desktop platforms, multiple applications can register identical custom URL schemes (e.g. myapp://oauth/callback). An attacker creates a rogue app that registers the same scheme. When the user completes authorization, the OS may route the redirect with the raw ?code=XYZ to the attacker's app.
The PKCE Defense: The legitimate client holds the private code_verifier in memory and only sends the SHA-256 hash (code_challenge) to the authorization server. Even if the attacker intercepts the code, they cannot exchange it at the token endpoint because they cannot supply the original plaintext verifier.
The Threat: An attacker initiates an OAuth flow, receives an authorization code linked to their own account, and halts the flow before redemption. They construct a link to the victim's app callback (/callback?code=ATTACKER_CODE) and trick the victim into clicking it. The victim's browser sends the request with their active session cookie, linking the victim's account or data to the attacker's credentials.
The State Defense: The client stores a cryptographically random, unguessable state token in an HttpOnly session cookie before redirecting to the provider. Upon return, the callback verifies that request.query.state === session.state. The attacker's forged link lacks the matching session token and is rejected.
The Threat: If an authorization server allows wildcard redirect URIs (e.g. https://*.example.com/*) or prefix matching, an attacker leverages an open redirector on a subdomain (e.g. https://blog.example.com/redirect?to=evil.com) to redirect the authorization code or token fragment directly to an attacker-controlled server.
The OAuth 2.1 Defense: Authorization servers must require strict, exact string comparison for registered redirect_uri values. Wildcards, path traversals, and query parameter expansions are prohibited.
The Threat: An attacker creates a malicious third-party app that prompts users to "Sign in with Google". Once the victim signs in, the attacker takes the issued ID Token or Access Token and sends it to your high-value enterprise API. If your API verifies the signature against Google's public keys but forgets to check the aud (audience) claim, it accepts the attacker's token and grants unauthorized access to the victim's data.
The Audience Defense: Every resource server and backend must verify that the aud claim in the token strictly equals its own registered client_id.
OAuth 2.0 & OIDC Modern Protocol Architecture
OAuth 2.0 (RFC 6749) is an authorization delegation framework, while OpenID Connect (OIDC) is an identity authentication layer built directly on top of OAuth 2.0. Understanding the cryptographic boundaries between client, authorization server, and resource server is essential for securing modern distributed architectures.
Architectural Showdowns: Protocol Design Comparisons
Mandates SHA-256 one-way hashing followed by Base64URL encoding. The authorization server never sees the plaintext verifier until token redemption.
- One-way cryptographic commitment prevents eavesdropping
- Mandatory for public and confidential clients in OAuth 2.1
- Mitigates TLS inspection and server log leakage
Sends the raw verifier string as the code_challenge directly in the URL query string, providing zero hashing protection.
- Exposed in proxy logs, browser history, and Referer headers
- Permitted only on severely resource-constrained microcontrollers
- Explicitly forbidden in OAuth 2.1 specifications
Tokens are issued only via a secure backchannel POST request to the token endpoint, sender-constrained by the ephemeral verifier.
- Tokens never touch browser address bar or referrer headers
- Enables issuance of cryptographically bound refresh tokens
- Universal standard for SPAs, mobile apps, and servers
Returns access tokens directly in the URL hash fragment (#access_token=...), completely bypassing client backchannel authentication.
- Tokens leaked to browser history and third-party scripts
- No refresh tokens permitted due to lack of client auth
- Officially removed in OAuth 2.1 and IETF BCP
Cryptographically signed JSON Web Tokens carrying claims (user ID, roles, scopes) validated statelessly using public keys (JWKS).
- Zero database lookup latency across microservices
- Standardized structure across vendors via RFC 7519
- Revocation requires short TTLs or distributed blocklists
High-entropy random strings with no embedded data. Resource servers query an introspection endpoint (RFC 7662) to resolve token metadata.
- Instant token revocation capability at authorization server
- No internal architecture details exposed to clients
- Requires network roundtrip for each API request
Five Fatal OAuth 2.0 & OIDC Implementation Pitfalls
Storing JWTs or bearer tokens in localStorage or sessionStorage provides zero protection against Cross-Site Scripting (XSS). Any third-party NPM dependency, unescaped user input, or compromised CDN script can execute localStorage.getItem('token') and exfiltrate authentication credentials. Production SPAs should use the Backend-For-Frontend (BFF) pattern or store tokens in encrypted, HttpOnly, SameSite=Strict cookies.
Treating the state parameter as optional or hardcoding a static string like state=12345 leaves the application completely vulnerable to CSRF login injection. Attackers can trick a logged-in user into visiting an authorization callback with the attacker's pre-generated code, permanently binding the victim's session to the attacker's identity.
Registering wildcard patterns such as https://*.example.com/* or https://example.com/oauth/callback?* enables attackers to exploit open redirectors or directory traversal flaws to forward authorization codes to external servers. OAuth 2.1 explicitly requires strict exact-string URL matching for all redirect URIs.
Naive JWT verification libraries that read the alg header from an incoming token and skip verification if alg: "none" is present allow attackers to forge arbitrary claims, grant themselves administrative privileges, and bypass all authentication checks. Production backends must enforce strict algorithm whitelisting (e.g. RS256, ES256) and reject unsigned tokens unconditionally.
Validating only the cryptographic signature of an ID token while ignoring the nonce and aud claims leaves the client open to replay attacks and confused deputy vulnerabilities. An ID token intercepted from another client belonging to the same identity provider can be replayed against your application unless the audience claim is rigorously validated.