Table of Contents
Authentication looks simple in a diagram. A user signs in, the application knows who they are, and access follows.
On a real network it is considerably less tidy. The credential is exchanged once, and after that a token or a session identifier travels back and forth across load balancers, reverse proxies, API gateways and service meshes, any of which can alter it, strip it or fail to forward it.
Most authentication faults are not authentication faults at all. They are transport faults, and they are diagnosed much faster once you know what is supposed to be in flight.
What Is Actually Moving
Two mechanisms dominate, and they behave differently in transit.
Session identifiers are the older model. The server holds the session state, the client holds a reference to it in a cookie, and every request carries that cookie back.
Cookie attributes govern whether that actually happens. MDN documents that a cookie with SameSite=Strict is sent only for same-site requests, that SameSite=None requires the Secure attribute or the browser rejects it, and that a Secure cookie is only transmitted over HTTPS.
That single paragraph explains a large share of production login failures. An architecture that authenticates on one domain and serves the application from another is a cross-site request, and a Strict cookie will simply not be there.
Tokens are the stateless model. The credential is exchanged for a bearer token which the client sends on each request, and the resource server validates it independently.
RFC 6749 defines the framework here, introducing an authorization layer that separates the client from the resource owner and issuing an access token that denotes a specific scope, lifetime and set of access attributes.
Scope and lifetime are the operative words. A token can be valid and still be rejected for lacking the right scope, which presents to the user as a login problem and is nothing of the kind.
Why B2B CIAM Architectures Break at the Proxy
Multi-tenant business applications sit behind more layers than consumer ones, which is where most of the trouble originates.
Ory documents its approach to multi-tenant identity for organization-scoped access, and in any b2b CIAM deployment the recurring failure is not the identity provider itself but the hops between it and the application, because tenant context has to survive every one of them.
Three specific breakages account for most incidents.
Headers dropped in transit. A proxy that does not forward the Authorization header produces an unauthenticated request at the origin, with no error anywhere in between.
Lost client context. Proxies replace the originating address with their own. RFC 7239 defines the Forwarded header precisely to let proxy components disclose information lost in the proxying process, including the originating IP address. Without it, any logic keyed to client IP behaves as though every request comes from one host.
Header size limits. Tokens carrying many claims can exceed a gateway’s header buffer. The request is rejected before reaching the application, and the log entry rarely mentions authentication.
Protocol Differences When Troubleshooting
The three common protocols fail in distinguishable ways, which is useful diagnostically.
SAML is XML over browser redirects, usually POST. Failures are typically signature validation, clock skew between identity provider and service provider, or an assertion consumer URL mismatch. The payload is large, so it breaks on size limits before the others do.
OIDC is JSON over HTTPS. Failures cluster around redirect URI mismatches, expired or unreachable signing keys, and audience claims that do not match the resource server.
Session cookies fail on domain, path, Secure and SameSite, as above, and on any proxy that rewrites the host header.
Federation adds another surface. NIST guidance on federation and assertions describes an identity provider conveying authentication attributes, and optionally subscriber attributes, to separately administered relying parties, and notes that relying parties may use more than one identity provider.
Separately administered is the phrase that matters. Two organizations, two clock sources, two certificate rotation schedules, and no shared change window.
A Practical Diagnostic Order
Work outward from the client rather than starting at the identity provider.
- Capture the request at the client. Confirm the cookie or the Authorization header is present and correctly formed.
- Capture it again at the origin. If it is present at one end and absent at the other, the fault is in a hop, not in the credential.
- Check the token contents. Decode it. Verify issuer, audience, scope and expiry before assuming anything is wrong upstream.
- Check clocks. Skew between components breaks signature and expiry validation silently.
- Check the hops individually. Load balancer, reverse proxy, gateway, mesh sidecar. Each is a candidate.
- Check header size limits if the payload is large.
Step two resolves more incidents than the other five combined, and it is the one most often skipped because the instinct is to suspect the identity provider first.
The Underlying Point
The credential exchange is a small part of authentication. The rest is a header surviving a journey through infrastructure that was configured by different people at different times for different reasons.
Treat it as a transport problem and the diagnosis gets considerably faster. Treat it as an identity problem and you will spend an afternoon reading provider logs that show a successful authentication for a request the application never saw.
ABOUT THE AUTHOR
IPwithease is aimed at sharing knowledge across varied domains like Network, Security, Virtualization, Software, Wireless, etc.
