Federation, in practice

What it means

Federation lets one system rely on identity information asserted by another. An identity provider authenticates the user and sends an assertion or token to a relying application through an established protocol. The application validates that message and decides what the user may do. This can reduce separate passwords and centralize some identity controls, but it creates an important trust relationship. Validation must cover the intended recipient, issuer, integrity, freshness, and relevant protocol protections. Account linking, user removal, and application sessions still require deliberate design.

The idea at a glance / Identity

Trust the issuer, then map the local account.

Keep the provider’s assertion, configured trust, local account mapping, and project permissions distinct. A trusted sign-in does not assign every project.

Fictional CampusID and ResearchSpace use a completed OIDC code flow. A validated CampusID assertion for researchspace-web names subject s842. The pre-provisioned (CampusID, s842) mapping is RS31, assigned only to project P3.

READ THE PICTURE

Read the separate scopes

CampusID’s valid assertion maps to ResearchSpace account RS31 under its configured trust and issuer–subject mapping. Independent application tests allow assigned project P3 and refuse unassigned P9. An identical subject label from another issuer would not be this mapping.

Keep in mindValidation and account linking are explicit assumptions of this snapshot, not live cryptographic results. Subject names are scoped to their issuer. Federation does not itself grant project membership or end every existing local session.

Read the complete example

Read the separate scopes. CampusID’s valid assertion maps to ResearchSpace account RS31 under its configured trust and issuer–subject mapping. Independent application tests allow assigned project P3 and refuse unassigned P9. An identical subject label from another issuer would not be this mapping. CampusID’s exact issuer is https://id.campus.example.test. The registered relying client is researchspace-web. A completed OIDC authorization-code flow has delivered a valid signed ID token with issuer CampusID, subject s842, and this audience. Configured issuer, signature, audience, expiration, nonce/transaction binding, and other applicable protocol checks have passed; this still is not a claim that those checks were performed against a live token. Required authentication and attribute release at the provider are assumed complete. ResearchSpace uses an explicitly pre-provisioned (issuer, subject) association to local account RS31, rather than guessing from an email address. The same s842 label issued by another IdP would be a different federated identifier and is not linked here. ResearchSpace establishes a separate local session and enforces its own membership policy: RS31 may read P3 but not P9. Independent synthetic tests return a P3 copy and refuse P9 while retaining both original projects and the valid local session. The IdP’s authentication relationship, the relying party’s validation/account linking, and local application authorization remain distinct. Neither a signed-looking assertion nor a valid provider authentication supplies unspecified permissions. Identifier, audience, and safe session references are explanatory labels, not credential values. Provisioning, linking changes, pairwise subject choices, proxy federation, key changes, and session/offboarding propagation require separate design. No production assertion or access check is executed by this comparison.

Validation and account linking are explicit assumptions of this snapshot, not live cryptographic results. Subject names are scoped to their issuer. Federation does not itself grant project membership or end every existing local session.

Diagram references: NIST SP 800-63C-4 - trust, identifiers, and separate sessions · OpenID Connect Core - issuer, audience, and flow validation

AN ILLUSTRATIVE SCENARIO

A university connects a research portal

A university lets researchers sign into a hosted collaboration portal using the university identity provider. A successful university login identifies the researcher, but the portal grants access only to the projects assigned to that identity. When a researcher leaves a project, the portal's project membership is removed. When the person leaves the university, the team also checks what happens to existing portal sessions and local fallback accounts; stopping new federated sign-ins may not immediately end every previously established session.

Put it to work

Choose a supported federation protocol and define the trusted identity provider, relying application, identifiers, and required attributes. Agree how users are provisioned, linked, updated, and removed.
Configure issuer and recipient validation, signatures or other required integrity protections, time limits, and protocol-specific replay defenses. Use maintained libraries and test key or certificate changes before they cause an outage.
Map identity information to narrowly scoped application permissions. Document session expiry, emergency access, and offboarding behavior so centralized authentication does not leave unmanaged local access paths.

How to check your work

Test a valid login, an unassigned user, an expired assertion, and a message intended for another application. Then disable a test identity and check both new sign-ins and existing application sessions against the documented revocation behavior.

Connect the ideas

SSO
A pattern where one authentication to an identity provider is reused across multiple applications.
Authentication
The act of verifying a claimed identity with authenticators such as passwords, passkeys, or certificates.
Authorization
The decision about whether a person, device, workload, or anonymous requester may perform a particular action on a resource.
Session
State linking multiple requests; an authenticated session associates later requests with a previously authenticated identity until it expires or is revoked.

Federation