Federation in one sentence
SSO within one organization, extended across organizational boundaries by way of a standing trust relationship between two parties. Northgate runs an IdP. Brightspace runs an SP. Northgate and Brightspace pre-agreed on a public key and metadata, so when a Northgate user shows up at Brightspace, Brightspace accepts Northgate's signed claim "this is alex" without ever talking to Northgate's user database.
The same pattern lets you "Sign in with Google" at a third-party site. Google is the IdP. The site is the RP (Relying Party — OIDC's word for SP). Google has previously registered the site and issued it a client ID, and the site has pre-configured Google's public keys. The plumbing is identical to enterprise SSO; only the parties differ.
SAML vs OIDC — the two protocols you will actually meet
Federation is implemented by two main standards. They solve the same problem with very different tools.
SAML 2.0
The enterprise default for two decades. Big, ceremonious, designed in an era when XML was thought to be the future of everything. The assertion is an XML document, signed with XML-DSig.
OpenID Connect (OIDC)
The modern default for consumer "Sign in with Google/Apple/Microsoft." Compact, JSON-based, friendly to JavaScript and mobile. The assertion is a JWT.
Practical rule: if it's enterprise software older than ~2018, it's SAML. If it's consumer or modern SaaS, it's OIDC. Most large IdPs (Okta, Microsoft Entra, Google) speak both.
The trust relationship — what's actually pre-arranged
Federation only works because each pair of (IdP, SP) has done paperwork in advance. The browser doesn't bring strangers together; it carries messages between parties that already know each other.
What gets exchanged at federation setup time
uid=alex,ou=Faculty; the SP wants email and full_name. The two sides agree on how to translate.Most federation outages and most federation breaches come from these five items being wrong, expired, leaked, or never reviewed. The XML or JSON looks unchanging; the trust assumptions inside it absolutely are not.
SP-initiated vs IdP-initiated flows
| Style | Where the user starts | What happens | Notes |
|---|---|---|---|
| SP-initiated | At the SP (e.g. brightspace.northgate.edu) | SP redirects user to IdP with a request, user authenticates, IdP returns the user to the SP with an assertion. | The normal path. Both SAML and OIDC support it. |
| IdP-initiated | At the IdP's portal (a tile gallery of available apps) | IdP generates an unsolicited assertion and POSTs it to the SP's ACS. | SAML-only. Discouraged because there is no request the assertion is answering — some CSRF-like attacks become possible. |
"Sign in with Google" — what's really happening
You click the button. In the next ~2 seconds:
- The site (the OIDC relying party) redirects your browser to
accounts.google.comwith parameters:client_id,redirect_uri,scope=openid email profile,state,nonce,response_type=code. - Google checks: is this client_id pre-registered? Is this redirect_uri on the allowed list for it? If yes, prompts you to log in (or recognizes your active Google session).
- You consent: "Allow My-App to see your email and name?" (only on first use, usually).
- Google redirects you back to the site's redirect_uri with a short-lived
codeparameter. - The site exchanges that
codeat Google's token endpoint (server-to-server, with the site's secret) for an ID Token (a JWT identifying you) and an access token. - The site verifies the ID Token's signature against Google's published JWKS, checks iss/aud/exp/nonce, and creates its own session for you.
The "complicated" part — the code-for-token exchange — is OAuth 2.0's Authorization Code grant. OIDC layers identity claims on top of it. See the OAuth page for what each grant type does and when to pick it; see the JWT page for what's inside the ID Token.
The attack surface every federation has
- Stolen IdP signing key. The Golden SAML attack: compromise the on-prem ADFS signing key, then mint tokens as anyone, forever. Used in the SolarWinds incident (2020). Mitigation: rotate keys regularly, keep them in HSMs, monitor for unexpected token issuance.
- SAML XML signature wrapping (XSW). The assertion is signed, but XML parsers and signature verifiers disagree on what they're looking at. Attacker wraps a forged assertion around a real signature. Recurring CVE class — libraries are still getting it wrong.
- OIDC misconfigured redirect_uri. Open redirects + wildcard redirect_uri allowlists let attackers steal tokens during the OIDC flow. See the OAuth page.
- JWT validation bugs. The relying party accepts
alg: none, fails to verify the signature, doesn't check audience or expiry, or accepts any algorithm including ones the IdP doesn't use. The next page (JWT) and the lab are about exactly this. - Account takeover at the IdP cascades everywhere. Phishable MFA on a Google account that's used for "Sign in with Google" everywhere takes every downstream account with it. Same lesson as enterprise SSO, with a broader blast radius.
- Stale federations. Companies merge, split, get acquired. SP entries at the IdP outlive the relationships they document. Aging federation metadata is a real risk class.