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.