Can I edit this OAuth 2.0 sequence diagram?

Yes — click Open in Editor to load this diagram into SeqDiagram.com. Adapt it for your own OAuth provider (Google, GitHub, Auth0, Okta) and export as PNG, SVG, or Mermaid. Free, no sign-up required.

OAuth 2.0 Sequence Diagram — Authorization Code Flow Example

Q: How does the OAuth 2.0 authorization code flow work?

The OAuth 2.0 authorization code flow works in steps: 1) Your app redirects the user to the OAuth provider's authorization endpoint. 2) The user logs in and grants consent. 3) The provider redirects back to your app with a short-lived authorization code. 4) Your app exchanges the code for an access token via a server-to-server call. 5) Your app uses the access token to call the resource server (e.g. Google APIs) on behalf of the user.

Q: What is the difference between OAuth 2.0 and OpenID Connect?

OAuth 2.0 is an authorization framework — it lets apps access resources on behalf of a user. OpenID Connect (OIDC) adds an identity layer on top: the token exchange also returns an ID token (a JWT) with user profile information, enabling authentication (login) rather than just authorization.

Diagram Source — edit it live in the browser

title OAuth 2.0 Authorization Flow

actor User
participant Browser
participant "Your App" as App
participant "OAuth Provider" as OAuth
participant "Resource Server" as RS

User->App: Click "Login with Google"
App-->Browser: Redirect to Google
Browser->OAuth: GET /authorize?client_id=...
OAuth-->Browser: Show login form
User->OAuth: Enter credentials
OAuth-->Browser: Redirect with auth code
Browser->App: GET /callback?code=xyz
App->OAuth: POST /token (code=xyz)
OAuth-->App: Access token + refresh token
App->RS: GET /userinfo (Bearer token)
RS-->App: User profile data
App-->Browser: Session created

What this diagram shows

This sequence diagram covers the OAuth 2.0 Authorization Code Flow — the recommended grant type for server-side web applications. It is the flow behind every "Login with Google", "Sign in with GitHub", and "Continue with Apple" button on the web.

The key security property this diagram makes visible: the authorization code travels through the browser (front-channel), but the token exchange happens server-to-server (back-channel) — so the access token never passes through the browser's redirect, preventing it from appearing in browser history or server logs.

Step-by-step flow breakdown

User initiates social loginUser clicks "Login with Google". Your app builds the authorization URL with client_id, redirect_uri, scope, and a random state parameter.

Browser redirected to OAuth providerThe app sends an HTTP redirect to Google's /authorize endpoint. The browser follows it and loads Google's login page.

User logs in and grants consentThe user authenticates with Google and sees a consent screen listing the requested scopes (e.g. "View your email address"). They click Allow.

Auth code returned via redirectGoogle redirects the browser to your redirect_uri with a short-lived code parameter (valid for ~10 minutes, single-use).

Server exchanges code for tokensYour app's backend POSTs the code to Google's /token endpoint along with client_secret. This is a back-channel call — the secret never touches the browser.

Access token + refresh token issuedGoogle returns an access token (short-lived) and optionally a refresh token (long-lived, for offline access).

App fetches user profileUsing the access token as a Bearer token, your app calls the resource server (e.g. Google's /userinfo endpoint) to get the user's profile data.

Session created, user logged inYour app creates a session, stores the user record, and redirects the browser to the authenticated area.

When to use an OAuth sequence diagram

SSO implementation docs — show the exact redirect chain so frontend and backend teams stay in sync
Security review — prove the client secret and access tokens never pass through the front-channel
Integrating a new provider — map out the provider-specific variations before coding
Debugging auth failures — trace which step produced the error (invalid state, expired code, wrong redirect URI)
Tech specs and RFCs — include the diagram alongside the implementation decision

Common variations

PKCE (Proof Key for Code Exchange)

For single-page apps or mobile apps that can't keep a client secret, add a code_verifier/code_challenge pair to the authorization request and token exchange. This replaces the client secret for public clients.

OpenID Connect (OIDC)

Add openid to the scope. The token response also returns an ID token (a signed JWT with user claims), enabling authentication on top of OAuth's authorization. Most "Sign in with Google" implementations use OIDC.

Refresh token flow

Add a separate sequence showing: access token expires → app sends refresh token to /token → new access token returned. This avoids forcing users to log in again.

Related sequence diagram examples

Frequently asked questions

How does the OAuth 2.0 authorization code flow work?

Your app redirects the user to the OAuth provider → user logs in and grants consent → provider redirects back with a one-time auth code → your server exchanges the code for an access token (back-channel) → your app uses the access token to call APIs on the user's behalf.

What is the difference between OAuth 2.0 and OpenID Connect?

OAuth 2.0 is an authorization framework — it grants apps access to resources. OpenID Connect (OIDC) adds an identity layer: it returns an ID token (JWT) with user profile claims, enabling authentication (login) not just resource access.

Why is the authorization code exchanged server-side?

The code exchange requires your client_secret, which must never be exposed to browsers or mobile apps. Doing the exchange server-to-server (back-channel) keeps the secret secure and ensures the access token never appears in browser history or server logs.

Can I edit this OAuth 2.0 diagram?

Yes — click Open in Editor. Adapt it for your provider (GitHub, Auth0, Okta, Azure AD) or add PKCE, OIDC, or refresh token steps. Export as PNG, SVG, or Mermaid. Free, no account required.

OAuth 2.0 Authorization Code Flow Sequence Diagram