Every developer who has played with OAuth 2.0 or OpenID Connect knows this moment: you need to double-check the exact sequence of a flow, and the diagram you remember seeing is scattered somewhere between a spec, a blog post, and a slide deck from a conference two years ago. The mechanism is well documented, but finding the right picture of it, at the right moment, is not.
That is the gap I built Identity Flow Diagrams to close, with Auth0 and my team backing me along the way.
What It Is
Identity Flow Diagrams is a website with one job: give developers and architects a fast, visual reference for the sequence diagrams behind common identity protocols. Each flow gets its own page with:
- A short introduction explaining what the flow is for and when to use it.
- A sequence diagram showing the full exchange between the parties involved.
- A step-by-step breakdown of what happens at each stage.
The goal is simple: be faster than digging through the spec or your own memory of a documentation page you read six months ago.
What Is There Today
The website is currently organized into four categories: User Login & SSO, Application & API Security, Security Enhancements, and Others.
Right now, that covers eight flows:
- OAuth 2.0 Authorization Code flow (and its PKCE variant).
- OpenID Connect Authorization Code flow with PKCE, the recommended login flow for most modern apps.
- OpenID Connect Implicit flow, included and explicitly marked as legacy since it is deprecated in favor of Authorization Code with PKCE, although it's still used in some contexts.
- SAML 2.0 SP-Initiated SSO, one of the most used SAML flows in the enterprise context.
- OpenID Connect Discovery, for retrieving a provider's configuration and public keys.
- DPoP-Bound Access Token Request and DPoP-Bound Access Token Usage, covering the mechanism for binding a token to a specific key pair.
While a static diagram gives you an overview of the whole flow, the interactive mode allows you to go through the flow and learn what happens at each step:
This Is an Early Release
I want to be upfront about where the project stands: this is a very first release, not a finished project. This initial flow set reflects what developers ask about most often, not everything that belongs on the website eventually. A few flows I am planning to add very soon:
- OAuth 2.0 Client Credentials flow, for machine-to-machine scenarios.
- OAuth 2.0 Device Authorization flow, for browserless and input-constrained devices.
- WebAuthn, for passwordless authentication.
There is also a longer backlog behind those, including Token Exchange, Private Key JWT authentication, and many more.
I Would Like Your Feedback
This is exactly the point in a project where feedback is most useful, before the shape of things is locked in. If you try identiflows.dev and something is unclear, missing, or just wrong, I want to hear about it. Just drop a message in the comment section below.
Top comments (3)
The interactive step-by-step mode is a game-changer. Most sequence diagrams show the whole flow at once, which is overwhelming for anyone learning OAuth. Being able to click through each step and see exactly what payload goes where is exactly how people actually learn.
One question on the roadmap: for the upcoming WebAuthn flow, are you planning to visualize the distinction between the platform authenticator (like TouchID/Windows Hello) and the roaming authenticator (like a YubiKey) in the sequence diagram? That's usually where people get the most confused.
Great resource, and congrats on the early release!
I'm aware that a diagram alone is not the best way to learn. I consider it more as a reference tool than a learning tool, because it lacks of context in most of the cases.
That said, I'd like to keep diagrams as simple as possible, so I think I will consider a generic "authenticator", regardless of the specific type. Probably I'll mention the existence of multiple authenticator types in one of the steps , or probably in a future release I will introduce an explanation of the actors involved in the flow. I'm not sure right now, but thanks for raising this 🙏
Keeping it generic makes sense for a reference. If you add too many specifics, the diagram becomes cluttered and stops being scannable. But I like the idea of mentioning that multiple authenticator types exist, even if you don't detail them all — it signals to the reader that there's more to learn.