OAuth Quick Reference

Analogy categoryAnalogies

This is a condensed reference for the terms, endpoints, and parameters you'll actually reach for while implementing or debugging OAuth 2.0, rather than a tutorial explaining each from scratch. It assumes you already know the basic shape of the authorization code flow and want a fast lookup for grant types, standard endpoints, token endpoint parameters, and common error codes without re-reading the full RFC. Keep it beside you while wiring up a new client or reading through server logs trying to figure out why a token exchange returned invalid_grant.

🏏

Cricket analogy: A quick reference is like a wicketkeeper's laminated card of field placements for each bowler, glanced at between overs rather than re-reading the full team strategy document mid-match.

Grant Types and Standard Endpoints

The four grant types you'll encounter most: authorization code (with PKCE) for web and native apps with a backend or app-level redirect handling, client credentials for machine-to-machine service authentication with no user involved, device authorization grant for input-constrained devices like smart TVs and CLIs, and refresh token for renewing an access token without re-prompting the user. The standard endpoints every authorization server exposes are /authorize (starts the interactive flow, returns a code via redirect), /token (exchanges a code, refresh token, or client credentials for an access token), /revoke (invalidates a token), and often /.well-known/openid-configuration (a discovery document listing every endpoint and supported capability for OpenID Connect providers).

🏏

Cricket analogy: The grant types are like the different match formats a board schedules in a season — Test for the long-form authorization code flow, T20 for the quick client-credentials handshake, and a rain-delayed match for the device flow's polling wait.

text

Grant types (grant_type value at /token):
  authorization_code   - web/native apps, requires code + code_verifier (PKCE)
  client_credentials   - machine-to-machine, requires client_id + client_secret
  refresh_token        - renew access token, requires refresh_token
  urn:ietf:params:oauth:grant-type:device_code - TVs/CLIs, requires device_code

Standard endpoints:
  /authorize   - starts the interactive flow, returns ?code=...&state=...
  /token       - exchanges a grant for access_token / refresh_token
  /revoke      - invalidates a given token
  /.well-known/openid-configuration - discovery document (OIDC providers)

Common /token error responses:
  invalid_grant     - code/refresh token expired, already used, or verifier mismatch
  invalid_client    - bad client_id/client_secret
  invalid_scope     - requested scope not granted or not registered
  redirect_uri_mismatch - redirect_uri doesn't exactly match the registered value

invalid_grant is the single most common error you'll see while debugging — it almost always means the authorization code was already redeemed once (codes are single-use), expired (usually a 60-second to 10-minute window), or the code_verifier didn't hash to the code_challenge you sent originally.

Token Types and Request Headers

An access_token is what you send on every resource server request, almost always as Authorization: Bearer <token>; a refresh_token is only ever sent to the /token endpoint, never to a resource server, and should be treated as more sensitive than the access token since it typically lives far longer. An id_token (OpenID Connect only) is a signed JWT describing the authenticated user and must be validated (signature, issuer, audience, expiry) rather than trusted blindly, while an access token's format is opaque by the OAuth 2.0 spec — some providers issue JWT access tokens, others issue opaque strings you must introspect via a /introspect endpoint to check validity. Scope strings are space-separated (e.g., openid profile orders.read orders.write), and the granted scopes actually returned can be narrower than what was requested if the user or policy denies part of it, so always check the scope field in the token response rather than assuming everything you asked for was granted.

🏏

Cricket analogy: Treating the refresh token as more sensitive than the access token is like a team guarding its full season contract more closely than a single match team-sheet — the access token expires next over, but a leaked long-term contract, like a leaked refresh token, causes damage for the whole season.

Four common grant types: authorization_code (with PKCE), client_credentials, refresh_token, and device_code.
Standard endpoints: /authorize, /token, /revoke, and /.well-known/openid-configuration for discovery.
Authorization codes are single-use and short-lived; reuse or expiry both produce an invalid_grant error.
invalid_client means a bad client_id/client_secret pair; invalid_scope means an unregistered or ungranted scope.
redirect_uri_mismatch means the value sent doesn't exactly match what was pre-registered.
The discovery document at /.well-known/openid-configuration lists every endpoint and supported capability.
Keep PKCE's code_verifier and the state parameter in mind first when debugging any authorization code flow failure.

Practice what you learned

1. Which grant type is appropriate for machine-to-machine service authentication with no user involved?

2. What does an invalid_grant error at the /token endpoint most commonly indicate?

3. What information does the /.well-known/openid-configuration document provide?

4. Which grant type is designed for devices like smart TVs that lack a full browser?

Was this page helpful?

OAuth Interview Questions

Related Study Notes in Programming

Browse all study notes

Programming

Apache Spark Study Notes

Programming · 30 topics

Programming

Apache Flink Study Notes

Programming · 30 topics

Programming

Hadoop Study Notes

Programming · 30 topics

Programming

Snowflake Study Notes

Programming · 30 topics

Programming

Apache Airflow Study Notes

Programming · 30 topics

Programming

dbt (Data Build Tool) Study Notes

Programming · 30 topics

Topics covered

#Programming#OAuth20StudyNotes#OAuthQuickReference#OAuth#Quick#Reference#Grant#StudyNotes#SkillVeris#ExamPrep

OAuth Quick Reference