OAuth 2.0 Authorization,
as a node-based flow.

This node-based flow diagram template maps every step of the OAuth 2.0 Authorization Code Grant flow, from the initial user login request through the authorization server redirect, code exchange, and final access token issuance. Each node represents a distinct actor or decision point — the client application, the resource owner (user), the authorization server, and the resource server — while directed edges show the precise sequence of HTTP requests and responses. The result is a clear, scannable visual that captures both the happy path and the conditional branches that occur when authorization is denied or tokens expire.

## When to Use This Template

This template is the right choice whenever your team needs to communicate how a web application delegates authentication to a third-party identity provider such as Google, GitHub, or an enterprise IdP. It is especially valuable during API design reviews, security audits, onboarding documentation for new engineers, and compliance walkthroughs where stakeholders need to verify that sensitive credentials never pass through the client. Because the Authorization Code Grant is the recommended flow for server-side applications and, with PKCE, for single-page apps and mobile clients, this diagram covers the most widely deployed OAuth pattern in production systems today.

## Common Mistakes to Avoid

One of the most frequent errors when diagramming this flow is collapsing the authorization code exchange and the access token request into a single node, which obscures the critical back-channel call that makes this grant type secure. Always represent the token endpoint request as a separate node with its own edge showing client credentials. Another common mistake is omitting the state parameter node; leaving it out implies the flow has no CSRF protection, which can mislead reviewers during security assessments. Finally, avoid drawing the resource server and the authorization server as the same node unless your architecture genuinely combines them — conflating the two hides an important trust boundary and can cause confusion when teams later add token introspection or a separate user-info endpoint. Keeping each actor as a distinct node ensures your diagram remains accurate as the system evolves.