Identity brokering is when your own identity provider (IdP) lets people sign in by delegating to another IdP, such as Google, GitHub, Okta or Microsoft Entra ID, and then issues its own session or token to your application. The application only ever talks to one issuer, and the broker handles every external login system behind it. This is why a product can offer “Sign in with Google” and a customer’s company single sign-on from the same login page without writing new code for each one. The component in the middle is often called an identity broker.
This post defines the term, shows what the application sees, explains the two common uses (social login and enterprise login), and covers the parts that trip teams up, such as account linking. If you are looking for the Keycloak-specific setup steps, the links in each section point to them.
What is identity brokering?
In a normal sign-in, your application sends the user to an identity provider, the user proves who they are, and the provider sends back a token. With brokering, there is a second hop: your identity provider does not check the credentials itself but sends the user on to another identity provider, which does. When the second provider confirms the user, the broker creates or finds the matching user in its own database and issues its own token to your application.
The application never learns which upstream system was used unless you choose to tell it. From its point of view there is one issuer, one set of signing keys and one token format. Keycloak documents this as identity brokering in its Server Administration Guide, and the same pattern exists in most identity products under names such as federation or connections.
How is a broker different from an identity provider?
A broker is an identity provider that also trusts other identity providers, so every broker is an IdP but not every IdP brokers. If you are new to the underlying terms, what is an identity provider is the place to start.
How is it different from federated identity?
Federated identity is the broader idea that one organization accepts identities that another organization manages. Brokering is one way to implement it, with a central party that sits between your applications and the external providers. For the business-to-business view, see our post on federated identity management for B2B SaaS and the comparison of federated SSO with a single identity hub.
What are the two kinds of identity brokering?
The mechanism is the same in both, but the reasons and the setup differ.
Social brokering
Here the upstream providers are consumer services such as Google, GitHub, Apple or Microsoft personal accounts. You register your broker as an application with each one, and users get a button for each on the login page. The goal is lower friction: nobody has to create yet another password. Our guides on adding GitHub social login with Keycloak brokering and social login implementation walk through it.
Enterprise brokering
Here the upstream provider belongs to a customer, for example the customer’s Okta or Entra ID tenant, connected through SAML or OpenID Connect. Each customer has their own connection, and their employees sign in with their work accounts. The goal is to meet a requirement that enterprise buyers raise early, which is that their IT team controls who can sign in.
A product that serves many customers ends up with many enterprise connections behind one login box. Routing each person to the right upstream provider, usually by email domain, is a separate topic. In Keycloak, Organizations (fully supported since Keycloak 26) link identity providers and email domains to a customer, and the kc_idp_hint parameter lets an application send a user straight to a specific provider.
What does your application actually see?
Your application sees one issuer and the same claims every time, and it needs no SDK per customer. That is the practical benefit, and it is the main reason to broker at all.
Without a broker, each new upstream provider means new code in your application: another redirect flow, another set of keys to validate, another mapping from that provider’s claim names to yours. An OpenID Connect provider such as Google sends a standard email claim, a SAML response from an enterprise customer may carry the same value under a differently named attribute, and a GitHub user can keep their email private, so it may have to be fetched separately. With a broker, those differences are absorbed in the broker’s mappers, which translate each upstream’s attributes into the claims your application expects. The application validates tokens from one issuer and reads the same claims every time. In Keycloak this translation is done with identity provider mappers, and attribute mapping during OIDC brokering shows how.
A related benefit is that you keep control of the token. You decide its lifetime, its audience and its claims, regardless of what the upstream provider sends. If a customer’s provider changes, the broker connection changes and your applications do not.
How do account linking and shadow users work?
When someone signs in through an upstream provider for the first time, the broker needs to decide who they are in its own database. There are three common outcomes in brokers generally. The broker creates a new local user, called a shadow user because it mirrors an identity held elsewhere. Or it finds an existing local user with the same email address and links the two. Or it asks the person to confirm by signing in to the existing account first.
The third option exists for a security reason. If a broker links accounts automatically on a matching email address, and an upstream provider does not verify email addresses, an attacker could register at that provider with someone else’s email and take over the matching account. Treat automatic linking as something you allow only for upstream providers you trust to verify email. In Keycloak this logic lives in the first broker login flow, whose default behaviour is the cautious one: if an account with the same email already exists, the user is asked to confirm by email or by signing in to the existing account, and automatic linking needs a custom flow or a deliberate trust setting for that provider. The error people see when the two collide is covered in account already exists, and a linking vulnerability from 2026 shows why the flow matters. Our post on shadow accounts, broker versus identity store goes into the detail.
How is brokering different from social login buttons or directory sync?
Brokering is often confused with two neighbouring things.
- Just adding social login buttons. You can add a Google button by integrating Google’s sign-in directly in your application, with no broker. That works for one provider and gets harder with each one added, and you end up writing the mapping and linking logic yourself. A broker moves that work out of the application.
- Directory sync. Brokering handles sign-in. It does not copy the customer’s user list into your system or remove people when they leave. For that you need provisioning, usually SCIM, as we describe in user provisioning explained. Enterprise customers commonly ask for both, so plan for them together.
When should you use an identity broker?
Use one when more than one upstream login system is likely to matter, and especially if the list will grow. Typical cases are a product that offers social login today and expects enterprise SSO next quarter, a B2B product with a different identity system at each customer, and an organization that is consolidating several directories after an acquisition.
You may not need one if you have a single login method for a small, fixed set of users, because a broker adds a component to run and secure. Even then, choosing an identity provider that can broker, which most can, keeps the option open.
Skycloak runs managed Keycloak, which includes brokering for social and enterprise providers, so connecting a new upstream provider is a configuration task and not an application change.
Frequently asked questions
What is the difference between an identity broker and an identity provider?
An identity provider authenticates users itself. An identity broker is an identity provider that can also hand authentication off to other providers and then issue its own token. The application sees the same thing in both cases.
Does identity brokering mean users have two accounts?
Not from the user’s point of view. The broker keeps a local record linked to the upstream identity, but the user only signs in once, through the upstream provider. Behind the scenes there are two records, the upstream account and the local linked one.
Is identity brokering the same as SSO?
It is related but not identical. SSO means a user signs in once and reaches several applications. Brokering describes how the sign-in is delegated to another provider. A broker is commonly used to deliver SSO, including company SSO for enterprise customers.
Is it safe to link accounts by email address?
Only when the upstream provider verifies email addresses and you trust it. Otherwise require the user to confirm by signing in to the existing account, which is the safer default.