title OAuth 2.0 Authorization Flow type actor User User -> Your App: click "Login with Google" Your App -> OAuth Provider: redirect to authorize User -> OAuth Provider: enter credentials & consent OAuth Provider -> Your App: auth code Your App -> OAuth Provider: exchange code for token OAuth Provider -> Your App: access token Your App -> Resource Server: request user profile Resource Server -> Your App: user profile data Your App -> User: session created
What this diagram shows
OAuth is confusing because half of it happens as browser redirects you never see in your network tab. Drawn out, it's two separate trips to the provider: one through the browser to get a code, and one server-to-server to swap that code for a token. Most explanations blur those together.
Google, GitHub, Microsoft: same flow. The provider box just changes its label.
Step-by-step flow breakdown
When to use this flow diagram
- Debugging a broken redirect by checking your flow against the standard one.
- Security review. It shows where the code and the token live at each step.
- Explaining OAuth to someone who's only ever used session cookies. This is the picture to send.
- Docs.
Common variations
PKCE for public clients
Add Your App -> Your App: generate code verifier before the redirect, and send the challenge along with the exchange.
Refresh tokens
Add a separate chain for Your App -> OAuth Provider: refresh access token, for when the token expires.
Scopes
Put the scopes on the redirect label: redirect to authorize (scope=email profile).
Related flow diagram examples
Frequently asked questions
What does an OAuth flow diagram show?
The full authorization code exchange: redirect, consent, code, token, resource. Every hop, including the two that hide behind browser redirects.
Does this work for any OAuth provider?
Yes. Any OAuth 2.0 provider follows this shape. Rename the provider box and you're done.
Can I use this template for free?
Yes. Open it, edit it, export PNG or SVG. No account.