IntegrAuth Academy
Identity, security and practical AI — free, from zero. Byte-sized lessons, real diagrams, hands-on labs, zero fluff. Two programs, each with its own exam and certificate.
English is hard? Your browser can translate this page into Tamil, Telugu, Kannada, Malayalam or Hindi. Tech words stay in English so you learn the real names.
How?
- Chrome on phone: ⋮ menu → Translate
- Chrome on computer: right-click → Translate to …
- Edge: the translate icon in the address bar
Getting a token — authorization code & PKCE
Maya taps "Sign in" on her pilates-booking app. A moment later the app holds its first access token and refresh token. Your goal: explain how a token is delivered safely, and why PKCE matters.
- Real tokens travel on the back channel. The browser carries only a one-time code.
- Three guards protect that code: exact return address, state and nonce.
- PKCE makes a stolen code useless.
- Use the code flow with PKCE. Do not use the implicit or password grant.
Two roads, one sign-in
The sign-in uses two roads. The front channel is the browser. A thief can copy what it carries. The back channel is a direct, encrypted call from the app's server to the identity provider. No browser sits in between. Real tokens travel only there. This is the authorization code flow of OAuth.
The one-time code
After Maya logs in, the identity provider gives the browser a short-lived code, like a claim ticket. The app's server swaps it for the real tokens on the back channel. Three guards protect the ticket:
🎯 Exact return address
The server sends the code only to a redirect_uri that was registered in advance. The match is letter for letter. No wildcards.
🔀 A state value
A random value, the state. The app plants it at the start and checks it on return. It ties the answer to this browser's own request.
🎲 A nonce
A one-time value, the nonce, placed inside the ID token. A copied login answer cannot be replayed later.
PKCE: a stolen code is worthless
Whoever shows the ticket gets the tokens. What if a thief copies the code? PKCE (say "pixie") stops this. It stands for Proof Key for Code Exchange. It works in four steps:
- Before the flow starts, the app's server makes a long random secret, the
code_verifier. - It sends only the hash of that secret up front, the
code_challenge. A hash is a one-way scramble. The method isS256, which means SHA-256. - To swap the code for tokens, the server must show the original verifier.
- The identity provider hashes it again. If the result differs from the stored challenge, it refuses.
The thief has the ticket but never saw the verifier. Their request fails with 400 invalid_grant.
A railway station cloakroom where you invent a secret word. You tell the clerk only a scrambled echo of it. To get your bag back, you must say the real word. A pickpocket with your slip cannot.
An attacker copies Maya's code on a bad network. Their POST /token has no verifier, so it gets invalid_grant. Maya's server swaps the same code with the real verifier. Her tokens are born.
Two old flows that are gone
Use the code flow with PKCE. Two older ways are gone. The implicit grant put tokens straight into the browser's address bar. That leaks. The password grant made the app collect Maya's real password. That breaks single sign-on, MFA and protection against phishing. PKCE cannot fix an app that sees the password. The newer OAuth rules leave both flows out.
Get the birth right, and every later defense has something sound to protect. Next: which token goes where.
Go deeper: more about the code flow
The state check guards against CSRF. A server that supports PKCE can also use the challenge for that job. Keep state anyway, because it is cheap. The nonce belongs to OpenID Connect and lives in the ID token.
A trickier danger is the "mix-up" attack. An app that talks to several identity providers can be fooled into sending a code to the wrong one. The fix is the iss value in the answer (RFC 9207). The app checks that it matches the provider it started with.
The verifier is 43 to 128 characters long. A code works only once. If a server sees a used code again, it should cancel the tokens that code produced.
Go deeper: the standards
PKCE is RFC 7636. RFC 9700 is the OAuth security best-practice guide, published in January 2025. It requires PKCE for public clients (apps that cannot keep a secret) and recommends it for every other client. It also forbids the password grant and advises against the implicit grant.
OAuth 2.1 is a draft that gathers these rules into one document. In October 2026 it was still an Internet-Draft, not yet an RFC. It asks for PKCE in every code flow. It leaves out the password grant, even for a company's own apps.
🧪 Interactive lab — enable JavaScript to play with this one.
Check the exact redirect_uri matching that this flow needs with Redirect Check. Then decode the ID token born at the end with ID Token Check.