Authentication gets weird the moment your system stops being a single app with a single session store.
In a monolith, you can often get away with a login form, a session cookie, and a few middleware checks. In a distributed system, that same user request might bounce through an API gateway, a backend-for-frontend, several microservices, a queue consumer, and a third-party API before the page finishes loading. Every hop adds a question: who is this caller, what proof do they carry, how long should that proof live, and who is allowed to turn that proof into something else? OAuth, OpenID Connect, token exchange, workload identity, mTLS, and fine-grained authorization all show up because the simple version breaks at scale.
That is the plain-English definition of designing authentication flows for distributed systems: deciding how identity is established once, propagated safely, constrained at every boundary, and re-validated without turning your architecture into a token graveyard. The trick is not to push one giant JWT through every service and hope for the best. The trick is to separate human identity from service identity, keep credentials short-lived, and make every hop prove just enough, and no more.
The industry is converging on a few hard truths
You can see the consensus in both the standards and the systems people actually run in production. Daniel Fett, Authlete, helped push modern OAuth security guidance toward sender-constrained tokens because bearer tokens are too easy to replay once copied. Ruoming Pang, Google, and the team behind Zanzibar approached the problem from another angle: once authorization spans globally distributed services, consistency matters as much as expressiveness, because access decisions need to reflect permission changes in the right order. Brian Campbell, Ping Identity, and other OAuth practitioners have spent years steering teams away from legacy OAuth patterns because the field has now seen enough real attacks to stop pretending old shortcuts are harmless.
The synthesis is useful. Modern authentication design is less about picking a fashionable protocol and more about reducing replay, reducing credential fan-out, reducing token lifetime, and reducing ambiguity about who is acting, the user, the app, or the service. That is also why current identity guidance increasingly favors phishing-resistant authentication at higher assurance levels, instead of treating passwords plus a one-time code as the finish line.
Start with a two-layer identity model
The cleanest mental model is to split identity into two lanes.
First, you authenticate the user. That is usually OpenID Connect on top of OAuth 2.0, with the authorization code flow and PKCE. OpenID Connect handles user authentication and identity claims, while OAuth handles delegated access to APIs. Modern OAuth guidance reflects years of security lessons, and one of the clearest signals is this: the industry has moved toward authorization code with PKCE and away from older browser-heavy shortcuts.
Second, you authenticate the workload. Inside the system, service A calling service B should not masquerade as “the frontend, somehow.” It should have its own verifiable identity. That is the job of workload identity systems such as SPIFFE and SPIRE, which let services receive short-lived identity material and use it for secure service-to-service authentication. In practice, this is the difference between a system that keeps copying secrets around and one that can rotate identity automatically at runtime.
That split sounds obvious, but teams skip it all the time. They let user tokens drift deep into the service graph, then every internal service becomes part identity provider, part policy engine, part incident report waiting to happen.
Design the user-to-service flow first, not last
Your public entry flow should be boring, and boring is good.
For browser and mobile clients, the baseline is usually an authorization server that authenticates the user, issues tokens through the authorization code flow, and sends the client an access token meant for a specific API audience. PKCE is the modern default because it reduces interception risk and avoids older exposure problems. If the client is a browser app, you also need to think about session boundaries, cookie settings, and logout behavior, because session handling is security-critical, not a UX afterthought.
A common production pattern is a backend-for-frontend, or BFF. Instead of handing powerful API tokens directly to JavaScript and then spraying them across downstream calls, the browser keeps a hardened session with the BFF, and the BFF handles API token use server-side. That reduces token exposure in the browser and gives you a cleaner place to enforce refresh, rotation, anomaly checks, and step-up authentication.
A simple worked example makes the tradeoff concrete. Suppose your user signs in and gets a 10-minute access token for api.example.com. If that token is then forwarded unchanged through gateway, orders, inventory, and billing, you have created four places where the same credential can be logged, replayed, over-scoped, or misunderstood. If instead the edge validates the user token once, and each downstream hop uses either workload identity or a down-scoped exchanged token, the blast radius drops sharply. That is not protocol theater; it is operational math.
Design the service-to-service flow so that credentials will leak
Because they will.
Inside a distributed system, the right question is rarely “how do I trust this token forever?” It is “how do I make stolen proof expire fast, fail closed, and reveal exactly which actor used it?” Modern OAuth security guidance exists because older patterns produced too many ways to leak and replay tokens. DPoP adds sender-constraining at the application layer, while token exchange lets one service trade a received token for another token with a different audience or reduced scope, instead of forwarding the original one everywhere.
This is where many architectures improve dramatically with one design change: stop treating internal hops as “trusted because VPC.” Use workload identity for the caller, and when the user context must continue downstream, propagate it explicitly as claims or as a delegated token, not as an all-access bearer credential. SPIFFE and SPIRE are attractive here because a workload can retrieve fresh identity material at runtime and use it for mTLS, while OAuth token exchange is attractive when a service legitimately needs a new token for a new audience. One gives you machine identity, the other gives you controlled delegation. Together, they are much safer than static API keys pasted into config.
The practical rule is simple: every hop should answer three questions with no hand-waving. Which workload is calling? Is there a user involved? Was this token minted for this audience and this action?
Keep authentication and authorization close, but not fused together
This is where a lot of “authentication flow” discussions quietly turn into authorization debt.
Authentication answers who the principal is. Authorization answers what that principal may do, on which object, under which relationship, right now. In a distributed system, especially one with shared documents, tenants, projects, folders, or delegated administration, role checks embedded in each microservice age badly. Zanzibar became influential because it showed a way to model and evaluate fine-grained permissions consistently at very large scale across many services. Systems inspired by that model, including newer cloud-native authorization platforms, exist because teams eventually discover that local role checks stop working once the business rules get real.
That does not mean every startup needs Zanzibar on day one. It means you should leave yourself a seam. Let authentication establish identity and issue proof. Let a dedicated policy layer decide access for sensitive operations. The moment your product supports “Alice can edit this document because she is an admin of team X, except when the document belongs to tenant Y and legal hold is enabled,” local role checks stop being cute.
Build the flow in four steps that survive production
Step 1: Pick one human login pattern and standardize it. Use OpenID Connect with authorization code flow and PKCE for user sign-in. Prefer phishing-resistant MFA, especially for admin and workforce access. Even if your compliance team has not forced the issue yet, this is where the security baseline is headed.
Step 2: Give workloads first-class identities. Stop sharing static secrets between services where possible. Use workload identity so services can authenticate to each other with short-lived credentials and mTLS. This shrinks secret sprawl and gives you better rotation and attribution.
Step 3: Down-scope at trust boundaries. When a service needs to call another service, exchange or mint a token for the new audience instead of forwarding the original token unchanged. Least privilege becomes real only when your tokens reflect the actual hop, audience, and duration.
Step 4: Centralize sensitive authorization checks. Keep object-level and relationship-heavy policy in a dedicated system or service, not copied across each microservice. That can be as simple as one policy service today, or as ambitious as a Zanzibar-style model later. The important part is consistency, traceability, and the ability to change policy without redeploying half the platform.
There are a few habits worth enforcing from day one:
- Log token audience and subject
- Keep tokens short-lived
- Rotate signing keys cleanly
- Make the actor explicit
That tiny bit of discipline saves days of incident response later.
The tradeoff nobody tells you about
The more distributed your authentication flow becomes, the more your real bottleneck shifts from cryptography to system design.
The hard parts are usually not “how do I validate a JWT?” There are questions like, “Which service is allowed to exchange tokens?”, “How do I revoke access fast enough?” “Where does tenant context live?” “What do async workers use when no browser session exists?”, and “How do I avoid making every outage look like an auth outage?” Standards help, but they do not answer architecture for you.
That is why the best authentication flows feel almost disappointingly restrained. User auth at the edge. Workload auth inside the mesh. Token exchange only where trust boundaries change. Central policy for high-value authorization. Everything else is simplification disguised as restraint, which is exactly what you want.
FAQ
Should every microservice validate end-user tokens itself?
Not necessarily. Edge validation plus controlled downstream propagation is often cleaner. What matters is that downstream services can trust the caller identity, understand whether a user is involved, and verify that any token they accept is intended for them. Token exchange and workload identity are often better tools than raw token forwarding.
When do you need a token exchange?
Use it when one service receives a token that is not appropriate to present to another service as-is, for example, because the audience, scope, or actor context needs to change. It is especially useful in delegation and impersonation-style cases where one hop should not inherit the full power of the previous hop.
Are JWTs enough for internal service authentication?
Usually no. A signed JWT can carry claims, but you still need a trustworthy way to establish which workload is presenting it, rotate credentials, and secure transport. That is why workload identity and mTLS show up in serious service-to-service designs.
Do passkeys matter for distributed systems?
Yes, at the human login edge. Passkeys and FIDO-based methods matter because they are phishing-resistant, which reduces the chance that your carefully designed downstream auth graph gets compromised by the oldest trick in the book, stolen credentials.
Honest Takeaway
Designing authentication flows for distributed systems is less like picking a library and more like laying out plumbing in a building that will keep expanding. You want pressure in the right places, shutoff valves at every floor, and no mysterious pipes disappearing into concrete.
The best default is also the least glamorous one: authenticate users with modern OIDC patterns, authenticate workloads separately, exchange or down-scope tokens when trust boundaries change, and keep fine-grained authorization out of random service code. Do that, and your auth system has a real chance of surviving growth, audits, and the inevitable “why is billing calling documents with a user token from three hops ago?” meeting.
