# OpenID Federation overview

Documentation owner: product `access`; documentation version: `next`.
Source: `content/products/access/next/authenticators/protocol-managers/oidc/openid-federation-overview.md` at commit `eaf7a020437971baeee95e87eaf963636040ac71`.

OpenID Federation lets an OIDC relying party (RP) establish trust in an OpenID Provider (OP) through signed metadata and a configured Trust Anchor. Access uses the resulting OP metadata for its OIDC login flow.

## How trust is established

Each federation participant has a public Entity ID and can publish a signed Entity Configuration at `<entity_id>/.well-known/openid-federation`. A superior federation entity can issue a signed Subordinate Statement about that participant. Access verifies a chain of these statements to a Trust Anchor whose public keys it already trusts, then applies the federation's metadata policy to obtain the OP metadata it will use.

The Entity ID in a signed statement identifies a federation participant. It is not the internal resource ID used to locate a configuration item in Access.

## The two Access components

| Component | Responsibility |
| --- | --- |
| Federation Entity | Publishes Access's signed Entity Configuration, holds the Trust Anchor configuration and resolves the selected OP. |
| OIDC RP authenticator | Starts and completes the OIDC authorization code flow, owns the redirect URI and RP protocol keys, and selects the OP. |

The OIDC RP links to the Federation Entity by its public Entity ID. The Federation Entity links back to the authenticator so that its published `openid_relying_party` metadata reflects the RP's configuration. Federation signing keys and RP protocol signing keys serve different purposes.

## Federation membership and client registration

Joining a federation and registering as a client with an OP are separate steps. A federation operator may need to issue a Subordinate Statement for Access's Entity ID before an OP can trust it. The RP then uses the client registration method supported by that OP and federation: automatic, explicit or pre-registered.

## Continue

Start with [Set up a federated RP in Management Center](/products/access/next/authenticators/protocol-managers/oidc/openid-federation-management-center/). For external testing, follow the [Sweden Connect Sandbox](/products/access/next/authenticators/protocol-managers/oidc/openid-federation-sweden-connect-sandbox/) or [OpenID Foundation](/products/access/next/authenticators/protocol-managers/oidc/openid-federation-conformance-testing/) guide. Use [manual configuration](/products/access/next/authenticators/protocol-managers/oidc/openid-federation-rp/) for the equivalent Access JSON resources and the [configuration reference](/products/access/next/authenticators/protocol-managers/oidc/openid-federation-configuration/) to look up individual settings. For persistent credentials and multi-node deployments, see [explicit registration and clustering](/products/access/next/authenticators/protocol-managers/oidc/openid-federation-explicit-registration/).

The protocol definitions are in [OpenID Federation 1.1](https://openid.net/specs/openid-federation-1_1-final.html) and [OpenID Federation for OpenID Connect 1.1](https://openid.net/specs/openid-federation-connect-1_1-final.html).