Distributed Authentication: OAuth2 and OIDC Federation

Introduction

Authentication in distributed systems poses a fundamental coordination problem.
When services span multiple trust domains, organizations, and network boundaries, no single authority can issue credentials that every participant trusts.
The challenge is not merely verifying identity but doing so without creating a centralized bottleneck or requiring every service to maintain bilateral trust relationships with every identity provider.

OAuth 2.0 and OpenID Connect (OIDC) have emerged as the dominant protocols for solving this problem.
OAuth 2.0 provides a framework for delegated authorization, while OIDC layers an identity and authentication protocol on top of it.
Federation extends both protocols across organizational boundaries, enabling users authenticated by one identity provider (IdP) to access resources governed by another.
Understanding these protocols at a systems level, not just at the API surface, is essential for building secure distributed architectures.

OAuth 2.0 as a Delegation Framework

OAuth 2.0 (RFC 6749) is not an authentication protocol.
It is an authorization delegation framework.
The core abstraction is the access token: an opaque or structured credential that a client application presents to a resource server.
The resource owner (typically a human user) grants the client limited access to their resources without sharing credentials directly.

The protocol defines four roles: resource owner, client, authorization server, and resource server.
It also defines multiple grant types (authorization code, client credentials, device code, and others) to accommodate different client architectures.
The authorization code grant, combined with PKCE (RFC 7636), is the recommended flow for most applications today.

A critical design property of OAuth 2.0 is the separation between the authorization server and the resource server.
These can be distinct services, operated by different teams or organizations.
The access token is the contract between them.
This separation enables the kind of loose coupling required in distributed systems, but it also introduces a token validation problem: the resource server must verify tokens without necessarily having a direct relationship with the authorization server.
Token introspection (RFC 7662) and self-contained tokens (JWTs per RFC 7519) are two approaches to solving this.

Token Validation Trade-offs

Opaque tokens require the resource server to call the authorization server's introspection endpoint on every request, introducing latency and a runtime dependency.
Self-contained JWTs can be validated locally using cached public keys, eliminating the runtime call but introducing revocation challenges.
A revoked JWT remains valid until it expires unless you layer on additional mechanisms (token revocation lists, short-lived tokens with refresh rotation, or a distributed cache of revoked token IDs).

In practice, most distributed systems use short-lived JWTs (5-15 minute expiry) combined with refresh tokens.
This bounds the window of vulnerability from a compromised token while keeping validation local and fast.

OpenID Connect: Authentication on Top of OAuth 2.0

OIDC adds an identity layer to OAuth 2.0 by introducing the ID token, a JWT that contains claims about the authentication event and the authenticated user.
While an OAuth 2.0 access token answers "what can this client do?", an OIDC ID token answers "who is this user, and how were they authenticated?"

OIDC defines a discovery mechanism (the .well-known/openid-configuration endpoint) that allows clients to dynamically locate an IdP's authorization endpoint, token endpoint, JWKS URI, and supported scopes.
This metadata-driven bootstrapping is the foundation of federation at scale: a relying party (RP) does not need pre-configured knowledge of every IdP if it can discover configuration from a trusted source.

The ID token includes standard claims such as iss (issuer), sub (subject identifier), aud (audience), exp (expiration), iat (issued at), and nonce.
The iss and sub pair forms a globally unique identifier for a user.
This is important in federated scenarios where the same person may have accounts at multiple IdPs.

OIDC Federation

OIDC Federation (defined in the OpenID Connect Federation 1.0 specification) addresses the problem of establishing trust between IdPs and RPs at scale.
In a bilateral trust model, every RP must be individually registered with every IdP.
This approach does not scale.
With N IdPs and M RPs, you need N × M trust relationships, each requiring manual configuration, client credential exchange, and ongoing maintenance.

OIDC Federation introduces a hierarchical trust model using entity statements and trust anchors.
The key concepts are:

• Entity Statement: A signed JWT that an entity publishes about itself (a self-signed statement) or that a superior entity publishes about a subordinate. It contains metadata, public keys, and policy constraints.
• Trust Anchor: A top-level entity whose public key is pre-configured in all participants. Analogous to a root CA in X.509 PKI.
• Trust Chain: An ordered sequence of entity statements from a leaf entity (an RP or IdP) up to a trust anchor. Validation requires verifying each signature in the chain and applying policy constraints at each level.
• Intermediate Entity: An entity that sits between a leaf and a trust anchor, enabling delegation. For example, a national research network might be an intermediate that vouches for university IdPs.

This model reduces the N × M problem to a tree structure.
An RP only needs to trust the anchor.
The anchor (or intermediaries) certifies IdPs, and the RP can dynamically resolve and validate trust chains at runtime.

Walkthrough

The following walkthrough describes how an RP validates trust in an IdP it has never seen before using OIDC Federation trust chain resolution.

1. RP receives an authentication request that references an unknown IdP
   with issuer URL: https://idp.university.example.org

2. RP fetches the IdP's self-signed entity statement:
   GET https://idp.university.example.org/.well-known/openid-federation
   Response: a signed JWT (ES_idp) containing:
     - IdP's public keys
     - IdP's OIDC provider metadata
     - authority_hints: ["https://federation.research-network.example.org"]

3. RP follows the authority_hints to resolve the intermediate entity:
   GET https://federation.research-network.example.org/.well-known/openid-federation
   Response: a signed JWT (ES_intermediate_self) containing:
     - Intermediate's public keys
     - authority_hints: ["https://trust-anchor.example.org"]

4. RP fetches the intermediate's statement ABOUT the IdP:
   GET https://federation.research-network.example.org/fetch?sub=https://idp.university.example.org
   Response: a signed JWT (ES_intermediate_about_idp) containing:
     - IdP's public keys (or a subset)
     - Metadata policy constraints (e.g., required scopes, allowed grant types)

5. RP follows authority_hints again to the trust anchor:
   GET https://trust-anchor.example.org/.well-known/openid-federation
   Response: ES_anchor_self

6. RP fetches the anchor's statement ABOUT the intermediate:
   GET https://trust-anchor.example.org/fetch?sub=https://federation.research-network.example.org
   Response: ES_anchor_about_intermediate

7. RP now has a trust chain:
   [ES_idp, ES_intermediate_about_idp, ES_anchor_about_intermediate]

8. RP validates the chain:
   a. Verify ES_anchor_about_intermediate is signed by the trust anchor's
      pre-configured public key.
   b. Verify ES_intermediate_about_idp is signed by the intermediate's
      public key (extracted from step 8a).
   c. Verify ES_idp is signed by the IdP's own key, and that the key
      matches what the intermediate certified in step 8b.
   d. Apply metadata policies at each level (intersection of allowed
      values, enforcement of required parameters).

9. If validation succeeds, RP now trusts the IdP's metadata and can
   initiate a standard OIDC authorization code flow with it.

This process is conceptually similar to X.509 certificate chain validation, but operates at the application layer with richer metadata and policy semantics.
Trust chains can be cached with TTLs derived from the exp claim in each entity statement.

Operational Considerations

Key rotation. Every entity in the federation must support key rotation without breaking trust chains.
OIDC Federation handles this through the JWKS published in entity statements, but operators must ensure that old keys remain available during transition windows.
The iat and exp claims in entity statements bound the validity of any given key binding.

Metadata policy. Intermediaries and trust anchors can impose policy constraints on subordinate entities.
For example, an anchor might require that all IdPs in the federation support PKCE, or that all RPs use only the authorization code grant.
These policies are expressed as JSON objects with operations like subset_of, superset_of, one_of, and value.
Policies are applied cumulatively down the chain, and any conflict results in a validation failure.

Clock skew. As with all token-based systems, clock synchronization matters.
Entity statements, ID tokens, and access tokens all have time-based validity.
In globally distributed deployments, NTP accuracy of a few seconds is typically sufficient, but the exp and nbf (not before) claims should include reasonable tolerance windows.

Scalability. Trust chain resolution involves multiple HTTP fetches.
In production, aggressive caching is necessary.
Entity statements are designed to be cacheable, with lifetimes on the order of hours or days.
The fetch endpoint calls can be parallelized when resolving multiple branches.

Key Points

• OAuth 2.0 is a delegation framework for authorization, not authentication. OIDC adds the identity layer by introducing the ID token.
• The separation of authorization server and resource server in OAuth 2.0 creates a token validation problem, solved by either introspection (runtime call) or self-contained JWTs (local validation with revocation trade-offs).
• OIDC Federation replaces bilateral N × M trust relationships with a hierarchical model using trust anchors, intermediaries, and entity statements.
• Trust chain resolution in OIDC Federation is analogous to X.509 certificate chain validation but operates at the application layer with richer metadata and policy enforcement.
• Metadata policies in the trust chain allow higher-level entities to constrain the security parameters of subordinate IdPs and RPs.
• Short-lived JWTs combined with refresh token rotation represent the practical consensus for balancing security and performance in distributed token validation.
• Clock synchronization, key rotation, and caching strategies are critical operational concerns that directly affect the reliability of federated authentication.

References

RFC 6749: The OAuth 2.0 Authorization Framework. D. Hardt. Internet Engineering Task Force, October 2012.

RFC 7519: JSON Web Token (JWT). M. Jones, J. Bradley, N. Sakimura. Internet Engineering Task Force, May 2015.

OpenID Connect Core 1.0. N. Sakimura, J. Bradley, M. Jones, B. de Medeiros, C. Mortimore. OpenID Foundation, November 2014.

OpenID Connect Federation 1.0. R. Hedberg, M.B. Jones, A.Å. Solberg, J. Bradley, G. De Marco, V. Dzhuvinov. OpenID Foundation, Draft 36, 2024.

RFC 7636: Proof Key for Code Exchange by OAuth Public Clients (PKCE). N. Sakimura, J. Bradley, N. Agarwal. Internet Engineering Task Force, September 2015.