OAuth 2.0 is an authorization framework that lets an application access a resource on behalf of a user without handling the user's password directly. This cheat sheet covers the main OAuth 2.0 flows used in modern web apps, mobile apps, single-page apps, and server-to-server systems. Students need it because OAuth diagrams can look complicated, but the same roles and token ideas appear in every flow.
Key Facts
- OAuth 2.0 is for authorization, while OpenID Connect adds authentication by introducing an ID token.
- The main OAuth roles are resource owner, client, authorization server, and resource server.
- In the authorization code flow, the client receives an authorization code first, then exchanges it for an access token at the token endpoint.
- PKCE uses code_challenge = BASE64URL(SHA256(code_verifier)) so a stolen authorization code cannot be used without the original verifier.
- The client credentials flow uses grant_type=client_credentials when one server needs access to another service without a user present.
- A refresh token is used to request a new access token, often with grant_type=refresh_token, without asking the user to sign in again.
- Scopes limit access by describing permissions such as read:profile, write:files, or payments:create.
- Access tokens should be short-lived, stored securely, sent over HTTPS, and included in requests as Authorization: Bearer access_token.
Vocabulary
- Access token
- A credential that a client sends to a resource server to access protected data or actions.
- Authorization code
- A short-lived code returned to the client after user approval and exchanged for tokens.
- PKCE
- Proof Key for Code Exchange, a security extension that protects public clients from stolen authorization codes.
- Scope
- A named permission that limits what a client is allowed to access.
- Refresh token
- A longer-lived credential used to obtain a new access token after the current one expires.
- Redirect URI
- The exact callback address where the authorization server sends the user after approval or denial.
Common Mistakes to Avoid
- Using OAuth 2.0 as proof of login, which is wrong because OAuth 2.0 alone authorizes access and does not reliably identify a user.
- Skipping PKCE for a mobile or single-page app, which is wrong because public clients cannot safely keep a client secret.
- Storing access tokens in unsafe browser storage, which is wrong because stolen tokens can be used as bearer credentials until they expire.
- Requesting broad scopes such as admin or full_access by default, which is wrong because apps should ask only for the minimum permissions they need.
- Accepting any redirect URI, which is wrong because attackers can redirect authorization codes or tokens to a malicious endpoint.
Practice Questions
- 1 An access token expires in 900 seconds. How many minutes is the token valid?
- 2 A client receives an authorization code at 10:05:20 and the code expires after 60 seconds. What is the latest time it should be exchanged?
- 3 A web app needs to read a user's profile and upload files. Write two example scopes that follow the pattern action:resource.
- 4 A single-page app cannot keep a client secret private. Explain why the authorization code flow with PKCE is safer than the old implicit flow.
Understanding OAuth 2.0 Flows Reference
A flow is really a sequence of trust checks. The browser is used because it already has a safe path to the service where a person signs in and gives consent. After consent, the service sends the browser back to a registered redirect address.
That address must match one of the addresses recorded for the application. This prevents an attacker from choosing their own return address and receiving a result meant for the real app.
The short code returned through the browser is deliberately less useful than a full access token. The app exchanges it through a direct protected connection, where the authorization server can check more details before issuing tokens.
PKCE protects public clients, such as mobile apps and browser based apps, because they cannot keep a secret hidden inside their code. Before sending a user to sign in, the app creates a long random verifier and makes a transformed version of it. It sends only the transformed version at first.
Later, when exchanging the code, it proves possession of the original verifier. An intercepted code is therefore not enough for an attacker. Students should notice that randomness matters here.
Predictable values defeat the purpose. PKCE is now good practice even for many server apps because it adds another check with little extra cost.
Scopes are part of the permission design, not just labels attached to a token. A well designed scope grants the smallest useful power. For example, an app that displays a calendar should not receive permission to delete every account setting.
Broad scopes make development easy at first, but they increase harm if a token leaks or a program has a bug. Consent screens should describe permissions in language people can understand.
A resource server must still check scopes for every protected action. It should not assume that a token permits all operations just because the token is valid.
Refresh tokens create a balance between convenience and risk. A short lived access token limits the time an attacker can use a stolen token. A refresh token can keep a session going, so it needs stronger protection than an access token.
Many systems rotate refresh tokens. Each use returns a new one and invalidates the old one. Reuse of an old token can signal theft and trigger session removal.
Server applications can store sensitive tokens in protected server storage. Browser code needs special care because page scripts and browser extensions may access unsafe storage. In real projects, developers also validate state values, use HTTPS everywhere, avoid putting tokens in web addresses, log failures without logging secrets, and test what happens when a token expires or permission is denied.