OAuth 2.0 Flow Specification Builder

Document your OAuth 2.0 implementation with flows, scopes, and tokens

Generate an OAuth 2.0 specification covering supported grant types, scope list, access and refresh token lifetimes, refresh rotation behavior, and standard error response codes. Outputs a clean Markdown reference for your API docs.

Which OAuth 2.0 grant type should I use?

For web and mobile apps acting on behalf of a user, use Authorization Code with PKCE. For machine-to-machine calls with no user, use Client Credentials. The legacy Implicit and Password grants are discouraged by current security guidance.

A single source of truth for your OAuth implementation

OAuth 2.0 has many moving parts — grant types, scopes, token lifetimes, rotation, and a fixed vocabulary of error codes. Client developers integrating with your API need all of it in one place. This builder produces a concise, accurate specification you can drop straight into your developer docs.

How it works

You choose which grant types your authorization server supports and define your scopes and token policy. The tool renders a Markdown reference with these sections:

  • Grant types — the selected flows, with a one-line note on when each applies. Authorization Code with PKCE for user-facing apps; Client Credentials for service-to-service.
  • Scopes — the permission strings clients can request, each with a human description. Least privilege is the rule: grant the narrowest scope that does the job.
  • Token lifetimes — access token TTL (kept short), refresh token TTL, and whether refresh tokens rotate on use.
  • Error responses — the standard RFC 6749 token endpoint errors so client code can branch correctly.

The whole document is generated in your browser; nothing is sent to a server.

Tips and example

Prefer Authorization Code with PKCE even for confidential web apps — it costs nothing and closes the code-interception attack. Reserve Client Credentials for back-end jobs that act as themselves, not on behalf of a user.

Keep access tokens short (15 minutes is a common default) and lean on refresh tokens with rotation for longevity. With rotation enabled, document the reuse-detection behavior: if an old refresh token is replayed, revoke the entire token family and force re-authentication.

Name scopes by resource and action, like orders:read and orders:write, so they read clearly in a consent screen. List every scope your API enforces — an undocumented scope is one a client cannot request correctly.