Visualize complex authentication handshakes with real-time sequence diagrams for Authorization Code, Implicit, and Client Credentials flows.
Select the grant type and configure the parameters to generate a corresponding sequence diagram and step-by-step breakdown.
The diagram below illustrates the request-response sequence between the User, Client, Authorization Server, and Resource Server.
Configure the parameters and click "Generate Diagram" to visualize the OAuth 2.0 flow.
Conceptual calculation: The visualizer maps the selected grant type to its RFC 6749 specification sequence. It identifies the actors involved, determines the request-response pairs for each step, and formats the payloads for display. PKCE adds an additional code verifier and challenge step in the Authorization Code flow.
Key assumptions: The flow assumes a standard browser-based application for Authorization Code and Implicit flows. Client Credentials assumes machine-to-machine communication. The redirect URI is assumed to be pre-registered and validated by the authorization server.
Limitations and edge cases: This tool visualizes standard flows. It does not cover extensions like SAML2 assertion grant, token exchange, or DPoP (Demonstrating Proof of Possession). Enterprise federation scenarios may involve additional steps not shown.
Select a grant type that matches your application architecture. For web applications with a backend, choose Authorization Code. For single-page applications without a backend, choose Authorization Code with PKCE. For machine-to-machine communication, choose Client Credentials.
Toggle PKCE for additional security when using Authorization Code in public clients. Select the scopes your application requires and click Generate Diagram to see the complete sequence.
The visualizer uses a deterministic mapping of OAuth 2.0 grant types to their defined sequences. Each grant type has a specific set of actors, requests, and responses defined in RFC 6749. PKCE modifies the Authorization Code flow by inserting a code verifier in the token request and a challenge in the authorization request.
The sequence diagram shows the actors across the top and time flowing downward. Solid arrows represent requests; dashed arrows represent redirects. Each step is numbered and corresponds to a detailed payload block below the diagram.
The security recommendations highlight best practices specific to the selected configuration, including PKCE requirements, state parameter usage, and token handling.
This tool visualizes OAuth 2.0 flows based on published RFC specifications. It is intended for educational and debugging purposes. The generated diagrams do not account for all implementation variations, security profile nuances, or server-specific behaviors.
Always conduct a thorough security review of your OAuth implementation before deploying to production, including penetration testing and compliance validation.
OAuth 2.0 is an authorization framework that enables applications to obtain limited access to user accounts on third-party services. Rather than sharing credentials, OAuth uses scoped access tokens issued by an authorization server. Understanding which grant type fits your architecture is critical for both usability and security.
The Authorization Code grant is the most secure option for applications that have a backend server. The user is redirected to the authorization server, authenticates, and grants permission. The authorization server redirects back with an authorization code, which the backend exchanges for tokens. This keeps tokens out of the browser where they could be intercepted.
When combined with PKCE, the Authorization Code flow becomes suitable for public clients like single-page applications and mobile apps that cannot securely store a client secret. PKCE adds a code verifier and challenge that prevents authorization code interception attacks.
The Implicit flow was designed for browser-based applications that could not store a client secret. It returns tokens directly in the redirect URI fragment. However, this introduces security risks: tokens in the browser history, potential exposure via browser extensions, and no way to verify token freshness via a backend. The OAuth 2.0 Security Best Current Practice BCP rejects Implicit for new implementations.
The Client Credentials grant is used for machine-to-machine communication where the client is also the resource owner. There is no user interaction; the client authenticates directly with the authorization server using its client credentials and receives an access token. This flow is appropriate for backend services, daemons, or microservices.
Proof Key for Code Exchange (PKCE, RFC 7636) was originally designed for mobile apps but has become recommended for all OAuth 2.0 implementations. Without PKCE, an attacker could intercept an authorization code and exchange it for tokens if they know the client ID. PKCE binds the token exchange to the original authorization request by requiring the client to prove it initiated the flow.
| Flow | Best For | Security Level | PKCE Required |
|---|---|---|---|
| Authorization Code | Web apps with backend, mobile apps | High (with PKCE) | Recommended for public clients |
| Authorization Code + PKCE | SPA, mobile apps, any public client | Highest | Required |
| Implicit | Legacy browser apps (deprecated) | Low | N/A |
| Client Credentials | Machine-to-machine, microservices | High | N/A |
Scopes define the permissions requested by the client. The authorization server presents the requested scopes to the user, who can grant or deny each one. The resulting access token is scoped to the granted permissions. Common scopes include openid for OIDC authentication, profile and email for user information, and custom scopes like read or write for API access.
The offline_access scope allows the client to receive a refresh token that can be used to obtain new access tokens without user interaction. This is useful for background data synchronization, email fetching, or long-running processes. However, it also presents a risk if the refresh token is compromised, so it should be protected accordingly.
The state parameter is an opaque value generated by the client that is included in the authorization request and returned unchanged in the redirect. Its primary purpose is to prevent cross-site request forgery attacks. When the redirect arrives back at the client, the state must be validated against the stored value before proceeding with the token exchange.
Access tokens are short-lived credentials that should be treated as opaque strings by the client. Store them securely, transmit them only over HTTPS, and do not log them. Refresh tokens should be stored in secure, server-side storage and never in browser localStorage for web applications.
The authorization server must validate the redirect URI exactly as registered. An attacker who can manipulate the redirect URI could intercept authorization codes or tokens via a URI they control. Exact string matching is recommended; wildcard patterns should be avoided unless absolutely necessary and then only with extreme caution.
Authorization Code with PKCE is the most secure flow for modern web applications, including single-page applications and mobile apps. It provides the security benefits of the Authorization Code flow while protecting against authorization code interception.
Authorization Code returns an authorization code that is exchanged for tokens on a backend server, keeping tokens out of the browser. Implicit returns tokens directly in the redirect, exposing them to browser-based attacks. Authorization Code is recommended for all new implementations.
PKCE protects against authorization code interception attacks where an attacker intercepts the code and exchanges it for tokens. By binding the token request to the original authorization request via a code verifier, PKCE ensures only the legitimate client can complete the exchange.
The redirect URI is where the authorization server sends the user after authentication, with either an authorization code or tokens. It must be pre-registered with the authorization server and validated exactly to prevent interception attacks via URI manipulation.
Refresh tokens appear in a subsequent flow after the initial authorization. The client presents the refresh token to the token endpoint and receives a new access token (and optionally a new refresh token). The diagram shows this as a separate loop after the initial authentication sequence.
Access tokens issued by an authorization server are meant to be used against a specific resource server (API). The resource server validates the token. CORS policies and token audience claims restrict which origins or clients can use the token. Refresh tokens are typically bound to the client that requested them.
Decode and inspect JSON Web Tokens to verify signatures, claims, and token expiration.
Generate cryptographically random code verifiers and their corresponding challenges for PKCE-enabled OAuth flows.
Diagnose Cross-Origin Resource Sharing configuration issues by inspecting response headers.
Fetch and validate OpenID Connect discovery documents and their well-known endpoints.
Debug WebAuthn registration and authentication flows with CBOR decoding and client data inspection.
Validate browser and device support for platform authenticators and passkey compatibility.
Create strong, random passwords with customizable character sets and length parameters.
Identify cryptographic hash algorithms from encoded strings for migration and forensics.