Chapter 17: Federation Between Organizations — Identity Across Corporate Boundaries

This is Part 17 of a chapter-by-chapter walkthrough of my book OpenID: Modern Identity for Developers and Architects. In the previous chapter we finished Part V with Zero Trust. Chapter 17 opens Part VI by asking a harder question: how do identity systems work across organizations that don't belong to you?

17.1 — B2B Identity

Most enterprises need to let partner-organization users in. Your vendor needs access to a portal. A contractor needs access to a repo. An auditor needs access to a system for a month. These are not employees, and you absolutely do not want to create accounts for them in your directory — that's the shadow-access problem from Chapter 10 made worse.

OIDC-based B2B federation solves this cleanly. Your application trusts the partner's IdP for authentication; authorization remains yours. The partner publishes their .well-known/openid-configuration, you configure them as a trusted issuer, and their users can log in while remaining their users.

17.2 — Partner Federation (Metadata, Keys, Claim Mapping)

Onboarding a federation partner is a procedure, not a one-time configuration. The partner publishes metadata; you validate it; you register their issuer and JWKS; you define which claims you'll trust from them; you establish a claim-mapping rule for the things they call differently (primary_email vs email, group naming conventions, locale formats).

The operational side matters as much as the security side: what happens when the partner rotates keys? When they deprecate their IdP? When an incident at their side means you should stop trusting their tokens immediately? Chapter 17 walks through the runbook.

17.3 — Trust Chains

Federation rarely stays bilateral. A trusts B, B trusts C — does A transitively trust C? The answer is usually "yes for some things, no for others." Trust frameworks formalize this: documented standards, required assurance levels, participant agreements. Federation operators (eduGAIN in academia, national schemes in several countries, industry consortia) run these at scale so every pair of participants doesn't have to negotiate from scratch.

The discipline: know exactly what you trust, know who you trust to make that trust judgment, and never conflate "authenticated" with "authorized for this specific action." The transitive case is where that conflation bites hardest.

What Chapter 17 Sets Up

After Chapter 17 you should be able to onboard a partner federation with clear eyes: what metadata to exchange, what claims to trust and normalize, what runbook you need for rotations and incidents, and how trust chains change the calculus. Partner access is where identity engineering meets contract law.

Next up — Chapter 18: Claims Design and Privacy. With federation in the mix, claims become both more necessary and more sensitive. We cover custom claim design, attribute mapping across providers, and privacy by design — minimization, selective disclosure, GDPR rights, and how OIDC's architecture supports (or fights) each of them.