OAuth 2.0 Flow Diagram — Authorization Code Example

Diagram source. Edit it live in the browser

title OAuth 2.0 Authorization Flow

type actor User

User -> Your App: log in
Your App -> OAuth Provider: redirect
User -> OAuth Provider: consent
OAuth Provider -> App Callback: auth code
App Callback <-> Token Endpoint: code for token
App Callback <-> Resource Server: get profile

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.

"Your App" and "App Callback" are the same application: the route that starts the login, and the route the provider sends the user back to. They're drawn as two boxes so the picture reads left to right. The two-way arrows on the right are server-to-server requests and their responses.

Google, GitHub, Microsoft: same flow. The provider box just changes its label.

Step-by-step flow breakdown

User starts the loginThe user clicks "Log in with Google" (or any provider) in your app.

Redirect to the providerYour app redirects the browser to the provider's authorize endpoint, with its client ID, the scopes it wants, a state value and the callback URL.

User signs in and consentsThe user signs in at the provider, not in your app, and approves the requested permissions.

Auth code sent to your callbackThe provider redirects the browser back to your callback URL with a short-lived authorization code. Your app checks that state matches what it sent.

Code exchanged for a tokenYour backend sends the code to the provider's token endpoint and gets an access token back. This call is server-to-server; it never goes through the browser.

Profile fetchedYour app calls the resource server with the access token, gets the user's profile, and signs the user in with its own session.

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.
Architecture and onboarding docs, where one picture saves a page of prose about redirects.

Common variations

PKCE for public clients

Add Your App -> Your App: generate code verifier before the redirect. The redirect carries the hashed code_challenge; the code exchange carries the original code_verifier. RFC 9700 makes PKCE mandatory for public clients such as single-page and mobile apps, and recommends it for everyone else. The OAuth 2.0 sequence diagram shows it call by call.

Refresh tokens

Add App Callback <-> Token Endpoint: refresh token for new access token for when the access token expires. It's the same endpoint as the code exchange, called with a different grant.

Scopes

Put the scopes on the redirect label: Your App -> OAuth Provider: redirect (scope=email profile).

Related flow diagram examples

Frequently asked questions

What does an OAuth flow diagram show?

The authorization code flow end to end: redirect, consent, code, token, profile. Every hop, including the two that happen as 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.

OAuth 2.0 Authorization Flow