The Authorization Code flow (with PKCE) is the right choice for almost every modern application, but the spec defines several other grant types, each suited to a different scenario — recognizing them, and knowing which ones are now discouraged, is common interview ground.
| Grant type | Used for | Status |
|---|---|---|
| Authorization Code (+ PKCE) | Web apps, mobile apps, SPAs — any flow involving a real user and a browser | Recommended default |
| Client Credentials | Machine-to-machine — a backend service calling another service's API with no human user involved at all | Standard, still current |
| Device Code | Devices with no browser or with painful text input — a smart TV, a CLI tool — showing a code the user enters on a second device | Standard, still current |
| Implicit | Historically, SPAs with no backend — returned an access token directly in the redirect URL, skipping the code exchange step | Deprecated — the token in the URL is exposed to browser history and referrer leaks; PKCE + Authorization Code replaces it |
| Resource Owner Password Credentials | Historically, a trusted first-party app collecting the user's username/password directly and exchanging them for a token | Deprecated — defeats OAuth's entire premise of never letting the client see the user's password |
Client Credentials flow (no user involved at all):
Backend Service A ---- POST client_id + client_secret ----> Authorization Server
Backend Service A <--------------- access_token -------------
Backend Service A ---- API call with access_token ---------> Backend Service B
Device Code flow (a smart TV app, for example):
TV App ---- requests a device code --------> Authorization Server
TV App <--- device_code + short user_code ---
TV App displays: "Go to google.com/device and enter ABCD-1234"
User, on their phone ---- enters user_code, logs in, approves ----> Authorization Server
TV App ---- polls the token endpoint until approved -------------> Authorization Server
TV App <--------------------- access_token ------------------------
The two deprecated flows are still worth recognizing on sight, because plenty of older documentation and legacy systems still reference them — the reason to avoid them in new code is exactly the browser-exposure and password-handling issues each one reintroduces.