RFC 6749 · explained step by step
Understand OAuth 2.0 by watching it run.
OAuth lets an app act on your behalf without ever seeing your password. Each flow here comes with a short explanation and a simulator you can step through, request by request.
authorization_code · 1 / 5
The app sends the user to the auth server and says which access it wants.
GET /authorize
?response_type=code
&client_id=my-app
&redirect_uri=https://app.example/cb
&scope=read:photos
&state=x7Kq2Nine flows, three purposes
A flow is one recipe for getting a token. Which one you need depends on who, or what, is asking for access.
When a user signs in
A person approves access to their data.
- Authorization CodeThe standard for web apps with a server.
- PKCEAuthorization Code for apps that cannot keep a secret, like mobile and browser apps.
- Device AuthorizationApprove a login on your phone for a TV or gadget with no keyboard.
- CIBAThe app starts the login and the user approves on their own phone, with no redirect.
When no user is involved
A program acts on its own behalf.
Building on top
Extensions that work alongside the flows above.
New to this? Read them in this order
Each step assumes only the ones before it. You can stop after the first two and already know most of what you will use.
- 01Authorization CodeThe core idea. Everything else builds on it.
- 02PKCEThe same flow, hardened for apps that cannot keep a secret.
- 03Refresh TokenHow sessions last longer than one short-lived token.
- 04OpenID ConnectAdds identity, so the app knows who the user is.
- 05Client CredentialsThe simplest flow, for machines.
- 06Device AuthorizationA special case for devices with no keyboard.
- 07JWT BearerA stronger way for a machine to prove who it is.
- 08Token ExchangeHow services pass a user's access along a chain of calls.
- 09CIBALogin started by the app and approved on the user's phone.