Cyber Security Academy · Lesson

OAuth 2.0 Flows

Authorization grants and tokens.

OAuth 2.0 Flows is a free Cyber Security Academy lesson on CoddyKit — lesson 1 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the Cyber Security Academy learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.

What OAuth 2.0 Actually Solves

OAuth 2.0 is a delegated authorization framework. It lets a user grant a third-party application limited access to their resources on another service without sharing their password.

It is about authorization (what an app may do), not authentication (who the user is).
The app receives a scoped access_token, never the user credentials.

Defenders must remember: OAuth alone does not prove identity. Treating an access token as proof of login is a classic mistake addressed by OIDC.

The Four Roles

Every OAuth flow involves four roles. Mapping them correctly is essential for threat modeling.

Resource Owner the user who owns the data.
Client the app requesting access.
Authorization Server (AS) issues tokens after consent.
Resource Server (RS) the API holding protected data, validates tokens.

Trust boundaries sit between these roles. A compromised client or a permissive AS undermines the whole chain.

Roles:
  Resource Owner  -> grants consent
  Client          -> requests + uses tokens
  Authorization Server -> issues tokens
  Resource Server -> validates tokens

Authorization Code Grant

The Authorization Code grant is the recommended flow for web and mobile apps. It separates user-facing redirection from the secret token exchange.

User is redirected to the AS to authenticate and consent.
AS returns a short-lived code to the registered redirect URI.
The client exchanges the code (server-side) for tokens over a back channel.

Because tokens are obtained on the back channel, they never appear in the browser address bar or history.

GET /authorize?response_type=code
  &client_id=app123
  &redirect_uri=https://app.example/cb
  &scope=read:profile
  &state=xyz

// then back-channel:
POST /token  grant_type=authorization_code&code=...

PKCE: Proof Key for Code Exchange

PKCE (RFC 7636) hardens the authorization code grant, and is now recommended for all clients including confidential ones.

Client generates a random code_verifier and sends its hash as code_challenge.
At token exchange it must present the original verifier.

This binds the code to the original requester, stopping an attacker who intercepts the authorization code from redeeming it.

code_verifier  = random 43-128 chars
code_challenge = BASE64URL(SHA256(verifier))

/authorize ... &code_challenge=...&code_challenge_method=S256
/token     ... &code_verifier=<original>

Client Credentials Grant

The Client Credentials grant is for machine-to-machine access where no user is involved (a backend service calling an API).

The client authenticates with its own credentials and receives an access token.
There is no user consent and no refresh token typically.

Scope these tokens tightly and rotate client secrets. Never use this flow to impersonate end users.

POST /token
  grant_type=client_credentials
  client_id=service-a
  client_secret=***
  scope=orders:read

Access Tokens vs Refresh Tokens

OAuth issues two main token types with very different lifetimes and handling rules.

Access token short-lived, sent to the resource server on every call. Treat as a bearer credential.
Refresh token long-lived, used only against the AS to obtain new access tokens.

Refresh tokens are high value. Store them securely, bind them to the client, and support revocation.

POST /token
  grant_type=refresh_token
  refresh_token=<long-lived>
  client_id=app123

Bearer Tokens and Transport

Most OAuth access tokens are bearer tokens: whoever holds the token can use it, like cash.

Always transmit over TLS; never in URLs where they leak into logs and referrers.
Send via the Authorization header.
Consider sender-constrained tokens (DPoP, mTLS) for high-risk APIs.

Authorization: Bearer eyJhbGciOiJSUzI1NiIs...

// AVOID:
GET /api/data?access_token=...   // leaks in logs

The Implicit Grant Is Deprecated

The legacy Implicit grant returned tokens directly in the redirect URI fragment. It is now discouraged by OAuth 2.0 Security BCP and removed in OAuth 2.1.

Tokens leaked through browser history, referrer headers, and logs.
No back channel meant weaker client authentication.

Use Authorization Code with PKCE for SPAs instead.

The state Parameter and CSRF

The state parameter protects the redirect step against CSRF. The client generates a random value, stores it in the session, and verifies it on the callback.

If returned state does not match, reject the response.
This prevents an attacker from injecting their own authorization code into a victim session.

before:  session.state = randomNonce()
/authorize ... &state=<nonce>

on callback:
  if (req.state !== session.state) reject()

Scopes and Least Privilege

Scopes express the granularity of access a token grants. Apply least privilege at every step.

Request only the scopes the feature needs (read:profile, not admin).
Resource servers must enforce scope on each endpoint, not just trust a valid token.

Over-broad consent is a common real-world risk: users approve apps that ask for far more than required.

Common OAuth Misconfigurations

Most OAuth incidents stem from configuration, not the protocol itself.

Open redirect / loose redirect_uri matching lets attackers steal codes.
Missing state or PKCE enables CSRF and code injection.
Long-lived access tokens with no revocation.
Treating an access token as an authentication assertion.

redirect_uri allowlist:
  EXACT: https://app.example/cb
  NOT:   https://app.example/*  (too broad)

Quick Check: Securing SPA Auth

Choose the correct, modern flow for the scenario below.

Recap: OAuth 2.0 Flows

Key takeaways:

OAuth 2.0 is delegated authorization, not authentication.
Four roles: resource owner, client, authorization server, resource server.
Authorization Code + PKCE is the default for web, mobile, and SPAs.
Client Credentials covers machine-to-machine access.
Protect with state, strict redirect URI matching, short-lived access tokens, and TLS everywhere.
Implicit and Password grants are deprecated.

Frequently asked questions

Is the “OAuth 2.0 Flows” lesson free?

Yes — the full text of “OAuth 2.0 Flows” is free to read here on the web, and the Cyber Security Academy course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the Cyber Security Academy course, upgrade to CoddyKit PRO.

What will I learn in “OAuth 2.0 Flows”?

Authorization grants and tokens. You practise Cyber Security Academy with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.

Do I need any experience to start Cyber Security Academy?

No prior experience is required. Cyber Security Academy on CoddyKit is structured for beginners through advanced learners; this is — lesson 1 of 4, so you can start here or from the beginning and move at your own pace.

How long does the “OAuth 2.0 Flows” lesson take?

Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.

Can I write and run code in this Cyber Security Academy lesson?

Yes. Every Cyber Security Academy lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.

All lessons in this course

← Back to Cyber Security Academy