Skip to main content
Identity Authority
Category: Federation & SSO

Identity Broker

Also known as: Identity Brokering Service, Identity Broker Service
Simply put

An identity broker is an intermediary service that sits between applications and multiple identity providers, so an application can accept logins from several different identity sources without integrating with each one directly. It establishes trust between the parties and passes along identity information, simplifying how sign-in is handled across systems. Depending on the deployment, it may handle both the login process and the passing of permission-related information.

Formal definition

An identity broker is an intermediary proxy service that connects multiple service providers (SPs) with multiple identity providers (IdPs), acting as a trust-establishment and translation layer between them. In typical deployments it federates authentication by relaying or normalizing identity assertions and claims from upstream IdPs to downstream SPs, so that each SP need only maintain a trust relationship with the broker rather than with every IdP individually. Some brokers additionally translate a caller's instruction into action using their own credentials and permissions, which can involve authorization-related handling in addition to authentication brokering; the exact split between authentication federation and authorization functions depends on the product and configuration. Note that the specific federation protocols supported (for example SAML 2.0, OpenID Connect, or OAuth 2.0) and the degree of claim transformation vary by vendor and are out of scope for this general definition.

Why it matters

As organizations accumulate applications and identity sources, internal directories, customer identity providers, partner federations, and social logins, the integration burden grows quadratically if every application must establish and maintain trust with every identity provider individually. An identity broker collapses this into a hub-and-spoke model: each service provider trusts the broker, and the broker manages the upstream relationships with identity providers. This reduces the number of point-to-point federations that must be configured, monitored, and rotated, which typically lowers operational overhead and shrinks the surface area where trust misconfigurations can occur.

Because the broker sits in the authentication path for many applications and often normalizes or transforms the claims that flow downstream, it becomes a concentration point of trust. That centralization is precisely what makes it valuable, but it also means the broker's own security posture, credential handling, and claim-transformation logic warrant close scrutiny, an error or compromise at the broker can affect every downstream service provider that depends on it. Where a broker additionally acts on a caller's instruction using its own credentials and permissions, the scope of what it can do extends beyond relaying authentication assertions into authorization-adjacent territory, and that expanded scope should be governed accordingly.

The practical boundary of any given broker's responsibilities varies. Some deployments limit the broker to federating authentication by relaying and normalizing assertions; others include authorization-related handling. Understanding exactly which functions a specific broker performs, and which it delegates to the identity providers or service providers on either side, is essential before treating it as a trust boundary in an architecture.

Who it's relevant to

Security architects
Architects use identity brokers to consolidate federation trust into a hub-and-spoke model, reducing the number of point-to-point relationships between service providers and identity providers. Because the broker becomes a concentration point of trust in the authentication path, architects must evaluate its security posture and decide whether its scope should be limited to authentication brokering or extended to authorization-related handling.
IAM and identity engineers
Engineers configure and operate the broker's connections to upstream identity providers and downstream service providers, including any claim normalization or transformation the deployment requires. They need to know precisely which federation functions the broker performs versus what it delegates, since the split between authentication federation and authorization functions depends on the product and configuration.
System administrators
Administrators managing environments with multiple identity sources rely on the broker so that each application can accept logins from several identity providers without integrating with each one directly. This simplifies onboarding of new applications and identity sources while centralizing where trust relationships are maintained and monitored.
Compliance and governance leads
Where a broker acts on a caller's instruction using its own credentials and permissions, its expanded scope extends beyond relaying authentication and should be governed accordingly. Governance leads should confirm which functions a specific broker performs before treating it as a trust boundary, and ensure the broker's handling of credentials and claim transformation is subject to appropriate oversight.

Inside Identity Broker

Federation Hub / Broker Endpoint
The central component that sits between service providers (relying parties) and one or more upstream identity providers, presenting a single integration point so that applications integrate with the broker rather than with each IdP directly.
Upstream Identity Provider Connectors
Configured trust relationships to external or internal IdPs, typically supporting protocols such as SAML 2.0 for web SSO and OpenID Connect (built on OAuth 2.0) for authentication. The set of supported protocols and profiles varies by product.
Protocol Translation Layer
Logic that mediates between differing federation protocols, for example, accepting a SAML 2.0 assertion from an upstream IdP and issuing an OpenID Connect ID token to a downstream relying party, or vice versa, depending on configuration.
Claims / Attribute Mapping and Transformation
Rules that map, rename, filter, or enrich identity attributes and claims received from the upstream IdP before they are passed to the relying party, so that downstream applications receive claims in an expected format.
Home Realm Discovery / IdP Selection
The mechanism by which the broker determines which upstream identity provider should authenticate a given user, whether by user selection, domain-based routing, or other configured logic.
Token and Assertion Issuance
The broker's function of issuing its own tokens or assertions to relying parties after an upstream authentication completes. Issued tokens are typically signed for integrity; signing is distinct from encryption, and confidentiality requires separate configuration.

Common questions

Answers to the questions practitioners most commonly ask about Identity Broker.

Is an identity broker the same as an identity provider (IdP)?
No, though the roles can overlap. An identity provider authenticates principals and asserts their identity, while an identity broker typically sits between service providers (relying parties) and one or more upstream identity providers, mediating and translating authentication and federation requests. A broker generally does not act as the authoritative source of the authentication itself; instead it delegates to upstream IdPs and normalizes the results. That said, some products bundle both roles, so in a given deployment the same component may perform brokering and act as a local IdP. Treating the two as strictly synonymous obscures the broker's core function of mediation and protocol translation.
Does an identity broker handle authorization decisions for the services it fronts?
Not inherently. An identity broker's primary function is typically federation and authentication mediation, verifying identity through upstream providers and passing normalized assertions or tokens to relying parties. Authorization, meaning what a principal is permitted to do, is a separate concern usually enforced by the relying party or a dedicated policy decision point and policy enforcement point. A broker may pass along attributes or claims that downstream authorization logic consumes, but forwarding attributes is not the same as making an access decision. Conflating the broker with an authorization engine blurs the line between authentication mediation and runtime access enforcement.
How does an identity broker handle protocol translation between upstream and downstream systems?
A common use of a broker is to bridge parties that speak different federation standards, for example, accepting a SAML 2.0 assertion from a relying party while authenticating the user against an upstream OpenID Connect provider, or vice versa. The broker terminates the inbound protocol, mediates the authentication with the upstream provider using that provider's protocol, and then issues a response in the format the downstream party expects. Depending on configuration, this may involve mapping and normalizing claims or attributes between the two representations. Because behavior varies by product and profile, the exact set of supported protocols and mappings should be confirmed against the specific implementation.
How should attribute and claim mapping be configured when a broker connects multiple upstream identity providers?
When a broker fronts several upstream providers, each provider may express identity attributes differently, so a mapping layer is typically configured to normalize incoming attributes and claims into a consistent representation for downstream relying parties. In most deployments this involves defining per-provider transformation rules that align source attributes to a common schema, and deciding how to handle missing or conflicting attributes. It is generally advisable to establish a canonical set of claims that relying parties depend on, then map each upstream provider into that set. The precise mapping capabilities and syntax depend on the specific broker implementation and should be validated against it.
What should be considered regarding the broker as a single point of failure?
Because a broker mediates authentication for potentially many relying parties and upstream providers, its availability directly affects login flows across those systems, so it is often treated as a critical component. In most deployments this leads to consideration of redundancy, high-availability configurations, and monitoring. Session and token behavior during broker outages depends on configuration, existing valid sessions or tokens may continue to function until expiry while new authentications fail. Capacity planning and failure handling for both the broker and its dependencies on upstream providers are typically part of the design, though specifics vary by vendor and deployment context.
How does session and token handling work when a broker sits between a relying party and upstream identity providers?
The broker typically establishes its own session or token relationship with each side rather than passing tokens through unchanged. When it authenticates a principal against an upstream provider, it usually receives a token or assertion from that provider and, separately, issues a token or assertion to the downstream relying party. This means there can be distinct session lifetimes and token validity periods on each side, and the relationship between them depends on configuration. Because the broker issues tokens the relying party trusts, its signing keys and validation configuration are security-sensitive, and how it correlates upstream and downstream sessions, including logout propagation, varies by implementation.

Common misconceptions

An identity broker authenticates users itself.
In most deployments the broker does not perform primary authentication of the user; it delegates authentication to an upstream identity provider and then relays or re-issues the resulting identity information. The authentication decision originates with the upstream IdP, while the broker mediates the exchange.
An identity broker handles authorization and enforces what users can access.
A broker's primary role is mediating authentication and federation, identification and authentication flows, not runtime authorization enforcement. Access decisions (PDP/PEP functions) and fine-grained authorization models such as RBAC or ABAC are typically handled separately, though a broker may pass attributes or claims that downstream systems use as authorization inputs.
An identity broker also performs identity governance tasks like provisioning and access reviews.
Brokering is a runtime federation concern and is distinct from IGA functions such as provisioning (for example via SCIM), access certification, and segregation of duties. Some products bundle both, but the brokering capability itself does not inherently manage the identity lifecycle.

Best practices

Explicitly document, per protocol profile (for example SAML 2.0 and OIDC Core), which upstream IdPs the broker trusts and how home realm discovery routes each user population, so trust boundaries are auditable.
Validate signatures on inbound assertions and tokens and, where confidentiality of claims is required, configure encryption separately, since a signed token is not an encrypted one.
Review and constrain claims/attribute mapping rules so that only the attributes downstream relying parties actually need are passed through, reducing over-exposure of identity data.
Treat the broker as a high-value single point of trust and dependency; plan for its availability and monitor it, because relying parties depend on it for authentication flows.
Keep runtime brokering configuration separate from and coordinated with IGA processes (provisioning, certification), rather than assuming the broker manages the identity lifecycle.
Where step-up or multi-factor requirements exist, verify how the broker propagates or requests authentication context from upstream IdPs, since MFA enforcement typically depends on the upstream provider and configured context signaling.
Promotional banner for the Penetration Report Template Kit