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
OIDC login step by step — the auth-code flow
Maya taps "Log in" and her dashboard opens. It feels like one click, but a few short messages fly behind it. Your goal: follow each step of the login and say where each secret lives.
- The front channel is the browser. Anyone can see it.
- The back channel is app server to login service. It is private.
- A one-time code crosses from the front channel to the back channel.
- PKCE makes a stolen code useless.
- The ID token is for the app. The access token is for APIs.
Picture it first
Maya opens a shopping app. She taps "Sign in with Google". The shop never sees her Google password. Here is what happens:
- The shop sends Maya to Google.
- Google checks that it is really her.
- Google sends her back to the shop with a one-time note.
- The shop shows the note to Google and gets proof of who she is.
That one-time note is the code in this lesson.
Two lanes
The front channel is everything that goes through Maya's browser: clicks, redirects and the address bar. Anyone watching can see it, and an attacker can try to change it.
The back channel is a direct talk between the app's own server and the identity provider (IdP). The IdP is the service that checks who you are. No browser is in the middle, so outsiders cannot see it. Secrets belong here.
The /authorize request
Next, the app sends Maya's browser to the IdP's /authorize address. It adds some parameters. Each one has a job:
| Parameter | What it is for |
|---|---|
client_id | The app's public name at the IdP. |
redirect_uri | The only address where the IdP may send the answer. |
scope | The permissions the app wants. |
state | A random value the app checks on return. It proves the reply belongs to this login. |
nonce | A second random value that goes inside the ID token. It proves the token was made fresh for this request. |
code_challenge | A one-way fingerprint of a secret the app keeps. The IdP asks for the secret later. This is PKCE (Proof Key for Code Exchange). |
Why a stolen code is useless
After Maya logs in, the IdP sends back an authorization code. It travels on the open front channel. But it works only once, and it lives for a very short time.
To swap it for tokens at /token, the app must also show the code_verifier. That is the secret behind the code_challenge from the first request. It never left the app's server. A thief has the code but not the verifier. The birth of a token tells the PKCE story in full.
Some old tutorials skip the code. They ask /authorize for tokens straight away, with response_type=token. This is the old implicit grant. Today's advice says stop using it, because tokens in the address bar leak. Use the code with PKCE instead.
a cloakroom ticket. To get the bag back, you must also say a passphrase that only you know. A photo of the ticket does not help a thief.
Two tokens
The swap at /token returns two tokens. They differ in who reads them.
🪪 id_token — for the app
It answers "who just logged in?" It holds Maya's user ID, her sign-in time and the nonce. The app reads it and starts a session. This is the ID token.
🔑 access_token — for APIs
It answers "what may be called?" It is a permission slip the app carries to APIs. APIs check it. The app need not look inside. This is the access token.
Never use an ID token to approve an API call. The audience is the app or API a token is meant for (see ID tokens vs access tokens). Then the app sets a session cookie, as the sessions lesson shows.
Almost every "Sign in with…" button uses this flow. It is the authorization-code flow with PKCE, on top of OpenID Connect.
Go deeper: what current advice says
RFC 9700 is the OAuth security guide from 2025. It says public clients must use PKCE. It says redirect addresses must match exactly. It says the old implicit grant should go, because tokens in the address bar leak. It says the password grant must not be used at all. A nonce does not stop tokens from leaking.
Go deeper: how sign-out works
Signing out has its own messages: RP-initiated, front-channel and back-channel logout. They get their own lesson: Signing out across apps. You can also replay both logout flows in the Flow Explorer.
Now play it. The lab runs the whole login one step at a time. Then you break it five ways, such as a wrong redirect or a stolen code.
🧪 Interactive lab — enable JavaScript to play with this one.
Decode the ID token from the end of this flow and check its claims with ID Token Check. Find redirect_uri mismatches with Redirect Check.