Category: OAuth & OIDC

OIDC Federation

Also known as: OpenID Connect Federation, OpenID Federation

Simply put

OIDC Federation is a way for separate systems to trust each other so that one system can accept a user's identity that was established by another. It relies on agreements between parties that trust each other, which lets applications authenticate users without each system having to manage its own credentials for them. This approach is often used as an alternative to long-lived static tokens for connecting different organizations or services.

Formal definition

OIDC Federation refers to establishing trust relationships among parties within the OpenID Connect ecosystem, where OpenID Connect is an authentication layer built on the OAuth 2.0 framework (IETF RFC 6749 and 6750). The OpenID Federation 1.0 specification expresses a federation as an agreement between parties that trust each other, using constructs such as Entity Statements to convey and chain trust between entities. In practice, OIDC Federation is a token-based trust model in which a relying system accepts identity assertions issued by another trusted system; in some deployments it is used to avoid distributing long-lived, static bearer tokens by relying on federated identity assertions instead. Note that specific federation topologies, trust-chain resolution, and metadata exchange mechanics depend on the profile and vendor implementation, and the exact scope of these varies by deployment.

Why it matters

OIDC Federation addresses a persistent challenge in multi-organization and multi-service environments: allowing one system to trust identities established by another without each system independently managing credentials for every user or peer. Because OpenID Connect is an authentication layer built on the OAuth 2.0 framework (IETF RFC 6749 and 6750), OIDC Federation extends that authentication capability across organizational and system boundaries through explicit trust agreements. This matters for architects designing federated ecosystems where the alternative, provisioning and maintaining separate credentials in every participating system, does not scale and increases the attack surface.

A significant driver for adopting OIDC Federation is the desire to move away from long-lived, static bearer tokens. In some deployments, such as connecting non-Databricks recipients to providers, OIDC federation is offered explicitly as an alternative to long-lived issued bearer tokens. Long-lived static tokens are attractive to attackers because, once exfiltrated, they can be replayed until they expire or are manually revoked; replacing them with federated identity assertions grounded in a trust relationship can reduce that exposure, depending on how the deployment is configured.

Because the exact federation topology, trust-chain resolution, and metadata exchange mechanics depend on the profile and vendor implementation, teams evaluating OIDC Federation should treat the trust model itself, not just the tokens it produces, as a security-critical design decision. Misconfigured trust chains or overly broad trust agreements can extend acceptance of identity assertions further than intended, so the scope of who trusts whom warrants careful review during design and audit.

Who it's relevant to

Security Architects

Architects designing cross-organization or cross-service identity flows use OIDC Federation to define which parties trust each other and how identity assertions propagate. Because trust-chain resolution and federation topology vary by profile and vendor implementation, architects must scope trust agreements deliberately and validate that acceptance of identity assertions does not extend beyond intended boundaries.

IAM Engineers

Engineers implementing federated authentication rely on OIDC Federation as an authentication layer built on OAuth 2.0 (RFC 6749 and 6750). They are often responsible for configuring Entity Statements and trust relationships per the OpenID Federation 1.0 specification, and for choosing federated identity assertions over long-lived static bearer tokens where a deployment supports that alternative.

Compliance and Governance Leads

Those responsible for governance and audit care about which systems accept identities established elsewhere and on what basis. OIDC Federation's reliance on explicit agreements between trusting parties gives governance teams a defined artifact to review, though they should confirm how each deployment resolves trust chains, since the exact scope varies by implementation.

System Administrators Integrating External Services

Administrators connecting external recipients or partner services, for example, connecting non-Databricks recipients to providers, may adopt OIDC federation as an alternative to issuing and rotating long-lived bearer tokens. They should verify the specific metadata exchange and token-handling behavior of their platform, as these mechanics depend on the vendor implementation.

Inside OIDC Federation

Entity Statement

A signed JWT that expresses metadata and trust information about an entity (such as an OpenID Provider, Relying Party, or intermediate authority). In OpenID Connect Federation, each participant publishes a self-signed entity statement describing its own configuration and keys.

Trust Anchor

An entity (typically a federation operator or top-level authority) whose public keys are known and trusted out of band. Trust chains are validated back to a trust anchor to establish whether a peer can be trusted, rather than relying solely on bilateral pre-registration.

Trust Chain

An ordered sequence of entity statements linking a leaf entity through one or more intermediate authorities up to a trust anchor. Resolving and validating this chain is how federation participants establish trust dynamically, depending on the profile and configuration.

Intermediate Authority

An entity that sits between leaf participants and a trust anchor, issuing subordinate statements about entities beneath it. This enables hierarchical, multi-party federations without requiring every pair of parties to be manually configured.

Metadata Policy

Constraints expressed by authorities in a trust chain that modify, restrict, or set the effective metadata of subordinate entities. This allows a federation operator to enforce baseline requirements on participants.

Federation Endpoints

Endpoints such as the federation fetch and resolve endpoints used to retrieve entity statements and resolve trust chains at runtime. Their availability and behavior depend on the specific deployment and profile in use.

Automatic/Explicit Client Registration

Mechanisms defined for federation whereby a Relying Party can register with an OpenID Provider based on a validated trust chain rather than manual out-of-band onboarding. The exact behavior varies by profile and configuration.

Common questions

Answers to the questions practitioners most commonly ask about OIDC Federation.

Is OIDC Federation just another name for OAuth 2.0 authorization between servers?

No. OAuth 2.0 is a delegated authorization framework and does not, on its own, authenticate users. OpenID Connect is the authentication layer built on top of OAuth 2.0, and OIDC Federation extends that authentication layer to establish trust between multiple OpenID Providers and Relying Parties. The federation concern is about how entities discover and trust one another for authentication, not about granting delegated access to resources. Conflating the two blurs the distinction between authentication and authorization.

Does OIDC Federation work the same way as SAML federation, so they are interchangeable?

They address a similar goal, establishing trust across identity domains, but are not interchangeable. SAML 2.0 is an XML-based federation standard oriented toward web SSO, while OIDC Federation builds on OpenID Connect, which itself sits on OAuth 2.0 and typically uses JSON and JWT-based artifacts. The trust establishment mechanisms, metadata formats, and message flows differ. Choosing between them depends on your ecosystem, existing infrastructure, and the profiles supported by your participants rather than one being universally superior.

How is trust typically established between entities in an OIDC Federation deployment?

In most deployments, trust is established through entity metadata that is cryptographically verifiable, often organized so participants can discover and validate one another rather than configuring each relationship manually. The exact mechanism, including how metadata is signed, chained, or resolved, depends on the specific federation profile in use. Because signing establishes integrity and authenticity but not confidentiality, verify whether your profile also requires encryption for any sensitive metadata or claims.

What should I validate when consuming ID tokens in a federated setup?

As a Relying Party you typically validate the ID token signature against keys traceable to a trusted issuer, confirm the issuer and audience claims, and check expiry and any nonce values per OIDC Core. In a federation, the added concern is confirming that the issuing OpenID Provider is a trusted federation participant according to your trust establishment mechanism. Note that ID tokens are used for authentication of the end user, distinct from access tokens used for authorization; do not treat them interchangeably. Exact required validations depend on the profile and your configuration.

How does OIDC Federation relate to provisioning and access reviews?

OIDC Federation is a runtime authentication and trust concern and is generally out of scope for identity governance and administration tasks such as provisioning, certification, and segregation of duties. Federation may authenticate a user and convey claims at sign-in, but lifecycle management of accounts and entitlements is typically handled separately, often via SCIM provisioning and IGA processes. Blurring these can lead to gaps where a user authenticates successfully but has no properly governed account or entitlements.

What operational factors should I plan for when scaling an OIDC Federation?

Key considerations typically include how entity metadata and signing keys are discovered, refreshed, and rotated; how key material and trust artifacts are cached and revoked; and how you handle onboarding and offboarding of participants. Behavior varies by federation profile and vendor implementation, so confirm what your chosen profile specifies for metadata resolution and trust chain validation. Also plan monitoring for failed signature or trust checks, since these often indicate stale keys or misconfigured participants rather than user error.

Common misconceptions

OIDC Federation is just OpenID Connect authentication for logging users in.

OpenID Connect itself is the authentication layer built on OAuth 2.0 that verifies who a user is. OIDC Federation is a distinct mechanism for establishing trust between many identity providers and relying parties at scale, typically through signed entity statements and trust chains resolved to a trust anchor. It governs how parties come to trust each other, not the act of authenticating an individual user.

Because entity statements are signed JWTs, the trust information they carry is confidential.

Signing provides integrity and authenticity, not confidentiality. A signed entity statement is not encrypted, so its metadata is generally readable by any party that fetches it. Confidentiality, where needed, must be handled separately depending on the deployment.

OIDC Federation removes the need for any pre-established trust between parties.

It reduces the need for bilateral, manual pre-registration of every pair of participants, but trust still ultimately depends on trust anchors whose keys are known and trusted out of band. In most deployments the trust anchor configuration is the root of the whole model.

Best practices

Distribute and pin trust anchor keys through a secure out-of-band process, since the entire trust chain validation depends on the integrity of the trust anchor.

Validate the full trust chain from a leaf entity's entity statement up to a recognized trust anchor before trusting a peer, and reject chains that cannot be fully resolved.

Apply and enforce metadata policies at intermediate authorities to constrain subordinate entities to your federation's baseline security requirements, depending on your profile.

Treat signed entity statements as integrity-protected but publicly readable; do not place data requiring confidentiality in them unless additional protection is applied.

Manage signing key rotation and entity statement expiration carefully so that trust chains remain resolvable and revocation or key changes propagate as expected in your deployment.

Keep federation trust establishment separate from runtime user authentication and authorization decisions, and document which profile and configuration your deployment relies on.