OAuth 2.0 Authorization,
as a requirement diagram.

This requirement diagram template visualizes the OAuth 2.0 Authorization Code Grant flow as a structured set of system requirements, constraints, and dependencies. It captures the key actors—client application, authorization server, and resource server—alongside the sequential requirements each must satisfy: redirecting the user to the authorization endpoint, exchanging the authorization code for an access token, and using that token to access protected resources. By representing these steps as formal requirements rather than a simple sequence diagram, teams can trace which components are responsible for which security obligations, making it easier to validate compliance and identify gaps before implementation begins.

## When to Use This Template

This template is especially valuable during the design and review phases of any system that integrates OAuth 2.0 for delegated authorization. Security architects use it to define acceptance criteria for each stage of the flow—such as PKCE enforcement, token expiry policies, and redirect URI validation—while development teams use it to align implementation work with documented specifications. It is also useful for compliance audits, where stakeholders need a clear, traceable record of how authorization requirements map to system components. If your team is onboarding a new identity provider, migrating from implicit flow to authorization code flow, or preparing documentation for a SOC 2 or ISO 27001 review, this diagram provides a structured starting point.

## Common Mistakes to Avoid

One frequent error is conflating requirements with implementation steps. A requirement diagram should state *what* the system must do—for example, "The client MUST validate the state parameter to prevent CSRF attacks"—not *how* it does it. Another common mistake is omitting security-critical requirements such as token storage constraints, scope validation, and the mandatory use of HTTPS for all redirect URIs. Teams also tend to overlook the refresh token lifecycle, failing to document requirements around rotation, revocation, and expiry. Finally, avoid listing requirements without assigning ownership to a specific component or actor; unowned requirements are rarely implemented or tested. Using this template correctly means every requirement is atomic, testable, and linked to the part of the OAuth flow it governs.