Topic guide · 2 min read
The social corridor: identity brokering explained
Short answer
An identity broker is a service that applications trust as their single identity provider, while it in turn trusts many upstream providers (social networks, customers' enterprise IdPs over SAML or OIDC, national eIDs), normalizing their different protocols and claims into one consistent token format and account model.
Key takeaways
- Apps integrate once with the broker; adding a provider does not touch application code.
- The broker maps each upstream identity to a local account and normalizes claims.
- It becomes a critical dependency: plan its availability, keys and exit path like any IdP.
Picture a corridor with many doors on one side and a single door on the other. Users arrive through whichever door suits them: a Google account, an Apple ID, their employer's SAML IdP, a bank-issued national eID. Applications only ever see the single door at the far end. That is identity brokering.
Why use a broker?
Because applications should not each integrate with every identity provider your users bring.
Without a broker, every app implements Google, Apple, Microsoft, three enterprise customers' SAML IdPs and a national eID, each with its own quirks, keys and claims. With a broker, each app speaks one protocol to one issuer. A new upstream provider is configured once.
How does a broker work?
It is a relying party toward upstream providers and an identity provider toward your applications.
- The app sends the user to the broker (OpenID Connect).
- The broker offers a choice of providers, or picks one from a hint such as the email domain (home realm discovery).
- The user authenticates upstream; the broker receives a SAML assertion or ID token and validates it.
- The broker finds or creates the local account and maps claims.
- It issues its own ID token and access token to the app.
Decode the broker's tokens with the JWT Decoder to confirm the normalized claims.
What does claim normalization involve?
Turning many attribute formats into one consistent set your applications can rely on.
| Upstream | Raw attribute | Normalized claim |
|---|---|---|
| Social OIDC | email, email_verified |
email, email_verified |
| Enterprise SAML | http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress |
email (verified by contract) |
| Enterprise SAML | memberOf groups |
roles (mapped per tenant) |
| National eID | Personal identity number | Kept in the broker; apps get a pairwise sub |
Note the last row: brokers are a good place to keep sensitive identifiers away from applications, issuing pairwise subject identifiers per app.
What are the risks?
The broker becomes a single point of trust and failure, and linking mistakes become everyone's problem.
- Protect its signing keys and admin access as described in the information security guide.
- Run it highly available; every sign-in depends on it.
- Apply strict account-linking rules, as covered in the social login guide.
- Record which upstream provider and assurance level each session came from, and pass it on (
amr,acr). - Keep an exit path: standard protocols on both sides and exportable account mappings.
Questions
Is an identity broker the same as a CIAM platform?
Brokering is one capability of most CIAM platforms. Open-source identity servers such as Keycloak also broker to upstream SAML and OIDC providers. The pattern is the same whichever product provides it.
Can a broker translate SAML to OpenID Connect?
Yes, that is a common use. The broker acts as a SAML service provider toward the upstream IdP and as an OpenID Provider toward your applications, issuing ID tokens built from the SAML assertion's attributes.