The reference desk / In practice

Federation

Trusting authentication assertions from an external identity provider instead of storing every password locally.

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.

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

  1. 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.
  2. 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.
  3. 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.

Explore a field lesson

Find your next idea.

Tip: press / to open search. Escape closes this window.