Authentication Architecture Diagrams: OAuth 2.0, JWT, and SSO Flows Visualized

How to diagram authentication and authorization systems clearly. Visual guides for OAuth 2.0, JWT token flows, SAML SSO, magic links, and MFA architectures.

Ryan·Senior AI Engineer

·Last updated May 29, 2026

Authentication systems are among the most consequential pieces of software your team will build — and among the hardest to communicate clearly. The flows are stateful, multi-party, and full of conditional paths (token expired? redirect to login; MFA required? prompt for code). A well-constructed authentication architecture diagram turns a confusing flow into something every engineer on the team can follow, review for security issues, and debug during an incident.

This guide covers how to diagram the most common authentication patterns: OAuth 2.0 authorization code flow, JWT-based session management, SAML SSO, passwordless / magic link auth, and multi-factor authentication. For each pattern, we include a prompt you can use to generate the diagram in seconds.

What an authentication architecture diagram should show

Authentication flows are sequence-heavy: they involve multiple parties exchanging messages in a specific order. A good auth diagram makes these things explicit:

All parties: User/browser, your application frontend, your backend/API, the identity provider (IdP), and any token validation service
Token lifecycle: Where tokens are issued, where they're stored (cookie, localStorage, memory), how they're validated, and when they expire or get revoked
Trust boundaries: What parts of the flow happen in the browser (untrusted), on your server (trusted), or via a third-party IdP
Error and edge-case paths: Token expired, invalid credentials, MFA challenge, account locked — these paths need to be visible, not implied
Data stored at each step: What gets written to the database during registration vs login vs token refresh

OAuth 2.0 authorization code flow

The OAuth 2.0 authorization code flow is the correct grant type for web applications where the backend can securely store client secrets. It's the pattern used by "Sign in with Google", "Sign in with GitHub", and similar social auth integrations.

"Show the OAuth 2.0 authorization code flow with PKCE. The user clicks 'Sign in with Google' on a Next.js frontend. The frontend generates a code_verifier and code_challenge and redirects the user to Google's authorization endpoint with the client_id, redirect_uri, scope, and code_challenge. Google authenticates the user and redirects back to the frontend's /auth/callback with an authorization code. The frontend sends the code and code_verifier to the backend API. The backend exchanges the code + code_verifier for access_token and refresh_token via Google's token endpoint. The backend stores the tokens in the database, creates a session, and sets an HTTP-only session cookie. Subsequent API requests include the cookie; the backend validates the session and uses the stored access_token for Google API calls."

Key things to show on this diagram: the PKCE challenge/verifier exchange, the authorization code that travels through the browser (untrusted), the token exchange that happens server-to-server (trusted), and the session cookie that replaces the tokens for subsequent requests.

JWT-based authentication

JSON Web Tokens (JWTs) are the most common session mechanism for APIs and SPAs. The architecture diagram needs to show the complete token lifecycle: issuance, storage, validation, refresh, and revocation.

"A user submits email + password to a React frontend. The frontend POSTs credentials to POST /auth/login on a Node.js API. The API validates credentials against the users table in PostgreSQL (bcrypt comparison). On success, the API signs a JWT access token (15-minute expiry) and a refresh token (7-day expiry) using RS256 private key. The access token is returned in the response body; the refresh token is set as an HTTP-only cookie. The frontend stores the access token in memory (not localStorage). On subsequent requests, the frontend includes the access token in the Authorization header. The API validates the JWT signature using the RS256 public key — no database lookup required. When the access token expires, the frontend calls POST /auth/refresh; the API validates the refresh token cookie, checks it hasn't been revoked in the refresh_tokens table, issues a new access token, and rotates the refresh token. On logout, the API deletes the refresh token from the database and clears the cookie."

SAML SSO for enterprise customers

SAML-based SSO is the enterprise-standard authentication pattern. If you're building B2B SaaS with enterprise customers, you'll need to support it. SAML flows are complex and multi-party — making them one of the most valuable flows to diagram explicitly.

"Show a SAML 2.0 SP-initiated SSO flow. The user visits app.example.com and is not authenticated. The Service Provider (SP — your app) generates a SAML AuthnRequest and redirects the user to the corporate Identity Provider (IdP — Okta or Azure AD). The IdP authenticates the user (username/password + MFA if configured). The IdP posts a signed SAML Response (containing the Assertion with user attributes: email, name, groups) to the SP's ACS URL (https://app.example.com/auth/saml/callback) via a browser POST. The SP validates the SAML Response signature using the IdP's X.509 certificate. The SP extracts the user attributes, looks up or provisions the user in the local database using email as the identifier, creates a session, and redirects the user to the original destination URL. Store the session in Redis with a 24-hour TTL."

Passwordless / magic link authentication

Magic link authentication eliminates passwords entirely: users enter their email, receive a time-limited link, and click it to authenticate. It's simpler to implement correctly than password-based auth and has better security properties (no password database to breach).

"The user enters their email on the login page and submits. The backend generates a cryptographically random 32-byte token, hashes it with SHA-256, and stores the hash in a magic_links table with the user's email, a 15-minute expiry timestamp, and a 'used' boolean. The backend sends an email via Resend containing a link like https://app.example.com/auth/verify?token=[raw_token]. The user clicks the link. The backend receives the token, hashes it, looks it up in magic_links, checks it hasn't expired and hasn't been used, marks it as used, looks up or creates the user by email, creates a session, sets a session cookie, and redirects to the dashboard. If the token is expired or already used, redirect to login with an error message."

Multi-factor authentication (TOTP)

Time-based One-Time Password (TOTP) MFA adds a second factor to password authentication. The architecture has two distinct phases — enrollment and verification — that should both appear in your diagram.

"Show TOTP MFA enrollment and verification flows.

Enrollment: The authenticated user navigates to security settings. The backend generates a random 20-byte TOTP secret, stores it temporarily in Redis (5-minute TTL) keyed to the user session, and returns the secret encoded as a base32 string and as an otpauth:// URI. The frontend displays a QR code (generated client-side from the URI) and a text input. The user scans with their authenticator app and enters the 6-digit code. The backend retrieves the temporary secret from Redis, validates the TOTP code using the TOTP algorithm (30-second window, ±1 step tolerance), and on success permanently stores the encrypted secret in the users table and marks MFA as enabled.

Verification at login: After correct password entry, if the user has MFA enabled, create a partial_session token (Redis, 5-minute TTL) and redirect to the MFA challenge screen. The user enters the 6-digit code. The backend validates the TOTP code against the stored secret, checks the used_otp_codes table to prevent replay attacks, creates a full session, and clears the partial_session."

Common auth architecture anti-patterns to show in your diagram

One of the most valuable uses of authentication architecture diagrams is security review. When the flow is visible, these anti-patterns become obvious:

Access tokens stored in localStorage: Visible if your diagram shows where tokens are stored — localStorage is accessible to any JavaScript on the page, making it vulnerable to XSS
Client secret exposed to the browser: Should never appear on the frontend side of any flow diagram; client secrets must only exist server-side
No token revocation: If your JWT diagram shows no revocation mechanism, there's no way to invalidate a stolen access token until it expires
Redirect URI not validated: OAuth flows where the redirect_uri isn't validated server-side are vulnerable to open redirect attacks
State parameter missing: OAuth flows without a state parameter are vulnerable to CSRF attacks — visible as a gap in the flow diagram

Auth system component reference

Component	Self-hosted options	Managed options
Identity provider (IdP)	Keycloak, Authentik, Zitadel	Auth0, Okta, WorkOS, Clerk
Session store	Redis, Memcached, PostgreSQL	Upstash, DynamoDB, Supabase
Token signing	RS256 / ES256 key pair (stored in secrets manager)	AWS KMS, GCP KMS, HashiCorp Vault
Email delivery (magic links, OTP)	Postfix, self-hosted SMTP	Resend, SendGrid, Postmark
Social OAuth providers	—	Google, GitHub, Apple, Microsoft
Enterprise SSO	Keycloak (SAML SP), Authentik	WorkOS, Okta SAML, Azure AD

Ready to try it yourself?

Start Creating - Free