█
LastWrite
  • > Curriculum
  • > Pricing
  • > For Educators
  • > About
  • > Contact
Log InGet Started

Questions, concerns, bug reports, or suggestions? We read every message, write to us at [email protected].

More ways to reach us →
LastWrite

Structured computer science lessons for aspiring developers and security professionals.

[email protected]

(201) 785-7951

Mon–Fri, 9 AM–5 PM EST

Learn

  • Curriculum
  • Pricing

Company

  • About
  • For Educators & Schools
  • Contact Us

Legal

  • Terms of Service
  • Privacy Policy
© 2026 LastWrite. All rights reserved.
Curriculum/Cybersecurity/Identity and Access Management/OAuth 2.0 and OIDC Flows
45 minIntermediate

OAuth 2.0 and OIDC Flows

After this lesson, you will be able to: Read an OAuth 2.0 / OIDC flow diagram, identify the security-critical steps, and spot common implementation vulnerabilities.

Every modern login (Sign in with Google, Microsoft, Apple) is OAuth 2.0 or OIDC under the hood. This lesson covers the four common flows, what each parameter actually does, and the misconfigurations that turn OAuth into account-takeover.

Prerequisites:Directory Services and SSO

The four flows you need to recognise

Authorization Code with PKCE, the default for almost every modern app (web, mobile, SPA). The user is redirected to the IdP, returns with a one-time code, the app exchanges the code for tokens. PKCE adds a per-request secret that prevents code interception. Client Credentials, machine-to-machine. No user involved; the app authenticates with its client_id and client_secret and gets an access token directly. Device Code, used on TVs and CLIs where typing is hard. The device shows a short code; the user types it on a phone. Implicit, legacy. Tokens came back in the URL fragment. Now deprecated, you should never use this for new apps.

App
generates a code_verifier + challenge
↓
IdP login page
user signs in; challenge is bound to the request
↓
Redirect back
with a one-time auth code
↓
Exchange
sends code + code_verifier
↓
Tokens
access + ID + refresh
Authorization Code flow with PKCE. The code_verifier proves the same app that started the flow is finishing it, so a stolen code is useless.

What a real authorization request looks like

Inspect this URL the next time you 'Sign in with Google'.

tsx
https://accounts.google.com/o/oauth2/v2/auth?
response_type=code
&client_id=12345.apps.googleusercontent.com
&redirect_uri=https://app.example.com/callback
&scope=openid+email+profile
&state=xyz-csrf-token
&code_challenge=E9Melhoa2OwvFrEMTJguCHaoeK1t8URWbuGJSstw-cM
&code_challenge_method=S256

The security-critical parameters

`state`, opaque value the app generates and verifies on callback. Without it, an attacker can CSRF the callback and force-link their account to the victim's session. `code_challenge` + `code_verifier` (PKCE), prevents an attacker who intercepts the authorization code (on a public Wi-Fi network, for example) from redeeming it. `redirect_uri`, must exactly match the registered URI on the IdP. A wildcard or open redirect here lets an attacker steal codes. This is the most common OAuth vulnerability in pentests. `scope`, the permissions the app is requesting. Always audit, lots of apps over-ask.

💡 OAuth is for authorization, OIDC is for authentication

OAuth alone gives the app an access token to call APIs on your behalf. It does NOT prove who you are. OIDC layers an ID token (a signed JWT containing your identity claims) on top. If an app uses raw OAuth and just trusts the access token as proof of identity, it is vulnerable to the access-token-confusion attack. Always use OIDC for login.

Hands-on: trace a real login

Watch a Google or Microsoft login in your browser's DevTools.

  1. 1

    Open an InPrivate/Incognito window and DevTools (Network tab, preserve log on)

  2. 2

    Sign into any site with 'Sign in with Google' or 'Sign in with Microsoft'

  3. 3

    Filter Network for the IdP domain (accounts.google.com or login.microsoftonline.com)

  4. 4

    Identify the initial authorize request, write down the values of response_type, scope, state, and code_challenge

  5. 5

    Find the callback hit on the app's domain, note the code and state parameters

  6. 6

    Locate the token exchange POST to the IdP's token endpoint and inspect the JSON response (access_token, id_token, refresh_token)

  7. 7

    Paste the id_token (a JWT) into jwt.io and read the claims: iss, sub, aud, email, name

Common OAuth vulnerabilities to look for in code review

Missing or non-random `state` (CSRF/login-CSRF). Loose `redirect_uri` validation (regex matching, wildcard subdomains, allowing path traversal). Using the implicit flow in new code (deprecated, no refresh tokens). Trusting the access token as proof of identity (use the id_token). Not validating the id_token signature, issuer, audience, and expiry. Logging full tokens to application logs (anyone with log access becomes the user).

Quick Check

What does PKCE prevent?

Choose the attack PKCE was designed to stop.

Sign in and purchase access to unlock this lesson.

Sign in to purchase
←Hands-on: AWS IAM Policies
Back to Identity and Access Management
Zero Trust Architecture→