How OAuth 2.0 Works: Authorization Code Flow, PKCE & Consent Phishing (Animated)

OAuth 2.0 lets you give an app limited access to your account at another service (“Let this photo app read my photos”) without giving it your password. The app gets a token with specific permissions (scopes). Tokens are powerful: steal or trick someone into granting one, and you don’t need their password.

1. Redirect to login: the app sends you to the provider

You click “Connect your photos”. The app doesn’t ask for your password; it redirects your browser to the login provider with what it wants.

1. CLICK (Your browser → Photo app): The user starts the flow.
2. 302 REDIRECT (Photo app → Your browser): The scope says exactly what the app wants: only to read photos.
3. GET (Your browser → Login provider): Your browser goes to the provider. Your password is only ever typed here.

What to look at:

The /authorize URL: client_id, redirect_uri, scope, state, code_challenge

2. Consent & code: you approve, the app gets a one-time code

You sign in at the provider and see a consent screen listing the permissions. If you click Allow, the browser is sent back to the app with a short-lived authorization code.

1. CONSENT (Login provider → Your browser): Read the permission list carefully: this is the moment of trust.
2. CALLBACK (Your browser → Photo app): The code itself is not access; it must be exchanged.

Check your own account:

Review “Third-party apps with account access” and remove anything you don’t recognise

3. Token exchange: code + secret → access token

The app’s server exchanges the code directly with the provider, proving with PKCE that it is the same app that started the flow. It receives an access token and usually a refresh token.

1. POST (Photo app → Login provider): Server to server: the browser never sees the tokens.
2. TOKENS (Login provider → Photo app): The app now holds tokens. It never learned the password.
3. GET (Photo app → Photos API): The API checks the token and its scope.
4. 200 OK (Photos API → Photo app): Least privilege in action: the token can read photos, nothing more.

Token tips:

Short-lived access tokens · refresh tokens stored server-side · never in URLs

4. Consent phishing: attack: tricking you into granting access

Instead of stealing a password, the attacker registers an app with a trustworthy-sounding name and sends a link. The consent page is real, from the real provider, but the app asks for broad scopes like reading all your mail, with offline access. One click on Allow, and changing your password later doesn’t revoke the token.

1. PHISH LINK (Malicious app → Your browser): The link goes to the real provider, so it looks safe.
2. CONSENT (Login provider → Your browser): A genuine consent screen asking for far too much.
3. TOKENS (Login provider → Malicious app): The user clicked Allow. The malicious app gets tokens.
4. GET (Malicious app → Photos API): The attacker reads the mailbox through the official API. A password reset doesn’t stop this.

What to look for:

Unfamiliar app names asking for mail, files or “offline access” permissions

5. Consent policies: defence: control which apps can ask

Organisations should block users from consenting to unverified apps (or require admin approval for sensitive scopes), regularly review granted apps, and revoke tokens during incident response. Users should read consent screens.

1. PHISH LINK (Malicious app → Your browser): Same trick.
2. BLOCKED (Login provider → Your browser): The user can’t approve it alone; the request goes to IT, who decline it.

Identity admin:

Allow user consent only for verified publishers and low-risk scopes
Review enterprise apps / OAuth grants monthly

FAQ