Volley

Volley / OAuth sequence diagrams

Examples

OAuth 2.0 sequence diagrams that show the actual requests.

Most OAuth diagrams show boxes and arrows and leave out the part you need: what each redirect carries and what the token endpoint returns. These two include it. Open either one in the editor and change it to match your provider.

Authorization code with PKCE

The flow for web and mobile apps that sign users in. The app never sees the password, and PKCE ties the code to the app that asked for it.

Open this diagram
Sequence diagram of the OAuth 2.0 authorization code flow with PKCE across User, Browser, App, Auth Server and API, with numbered steps, the authorize redirect, the token request, success and error branches, and the profile call.

What each step carries

  1. The app prepares. It generates a random state and a code_verifier, and hashes the verifier into a code_challenge with SHA-256.
  2. The browser is sent to the authorize endpoint. The query has response_type=code, client_id, redirect_uri, scope, state, code_challenge and code_challenge_method=S256.
  3. The user signs in and consents on the auth server's own page.
  4. The auth server redirects back to the callback with a short-lived code and the same state. The app rejects the response if state does not match.
  5. The app exchanges the code. A form-encoded POST /token with grant_type=authorization_code, the code, the redirect URI and the original code_verifier.
  6. The token response. On success, a JSON body with access_token, token_type, expires_in, and often refresh_token and id_token. On an expired or reused code, a 400 with invalid_grant. The diagram shows both as an if/else.
  7. The app calls the API with Authorization: Bearer and the access token.

In the editor every one of those payloads is one click away: select an arrow to see its parameters as a table or as the raw body.

Client credentials

The machine-to-machine flow. A backend service trades its own credentials for a token, with no user and no browser.

Open this diagram
Sequence diagram of the OAuth 2.0 client credentials flow: Service posts to the Auth Server token endpoint, receives an access token, and calls the API for open invoices.
  1. Token request. POST /oauth2/token with grant_type=client_credentials, the client id and secret, and the scopes it needs.
  2. Token response. A bearer token with a short lifetime. There is no refresh token in this flow; the service asks again.
  3. API call. The token goes in the Authorization header.

Check them against your provider

Providers differ in small ways that break clients: a string where you expected a number, a missing scope, a 401 instead of a 400. Record a real sign-in in your browser and run Drift Check on the diagram. Our client credentials demo catches exactly that kind of drift.

More sign-in flows

Templates for Sign in with GitHub and SAML single sign-on show the same level of detail for those protocols.

Write your own

Each diagram is a short text file. An arrow is App -> Auth Server: POST /token; the lines under it starting with in: and out: hold the request and response. The syntax guide covers notes, branches, dividers and icons.

Start from a working OAuth flow.

Open the example, swap in your provider's endpoints, and share the link.

Open the editorRead the syntax guide