Having established the roles of the OAuth framework, we must now determine how the token is actually acquired. A 'Grant Type' is simply the method a client uses to get an access token, and the choice depends entirely on the type of application being built.
This is the most secure and common flow. It uses a temporary 'Authorization Code' that the client exchanges for a token on a secure back-channel (server-to-server), ensuring the token never touches the user's browser.
💡 This flow is mandatory for 'Confidential Clients' (apps with a secure backend) because the Client Secret is never exposed to the end-user.
The server-side exchange shown above is what prevents the token from being intercepted by browser extensions or malicious scripts on the frontend.
The Implicit Grant is now deprecated. It used to return tokens directly in the URL fragment, making them highly susceptible to leakage.
# Client Credentials Flow (Machine-to-Machine)
# Used when there is no 'User' (e.g., a cron job syncing data)
curl -X POST https://auth.com/token \n-u "client_id:client_secret" \n-d "grant_type=client_credentials"| Grant Type | Best For | Security Level | Key Characteristic |
|---|---|---|---|
| Auth Code | Web Apps w/ Backend | High | Code $ o$ Token exchange |
| Implicit | Legacy JS Apps | Low | Token in URL (Deprecated) |
| Client Credentials | Microservices/Daemons | High | No user involved |
| Password Grant | First-party Apps | Low | User gives password to app |
When architecting a system, the default choice should always be the Authorization Code grant. If the client is a mobile app or a Single Page App (SPA) with no backend, PKCE must be added to this flow.
Using the Password Grant (Resource Owner Password Credentials) effectively destroys the primary goal of OAuth: allowing users to grant access without sharing their password.
Verify exercises to earn ★ 210 XP and unlock next lab level.