An identity broker is an intermediary in a federated sign-in process. It validates identity information from an upstream identity provider (IdP) and issues a new assertion or token that a downstream application can trust.
This approach becomes useful when organizations must connect multiple identity providers and applications with different federation requirements. Instead of configuring every relationship separately, IT teams can use a broker to manage supported trust relationships, identity mappings, and authentication routing.
The broker acts as a relying party toward the upstream IdP and as an identity provider toward the application. However, it also becomes a critical security and availability dependency. If direct federation already meets the requirement, adding a broker may create unnecessary complexity.
Key Takeaways
- An identity broker is a federation intermediary that validates identity information from an upstream identity provider (IdP) and issues a trusted assertion or token to a downstream application.
- Identity brokers simplify federation by centralizing trust relationships, mapping identity claims, and supporting protocol translation where available.
- Use an identity broker when multiple IdPs, incompatible federation requirements, or complex integrations make direct federation difficult to manage.
- Direct federation is preferable when applications and IdPs are compatible and an intermediary would add unnecessary complexity.
- Security is critical: Identity brokers require strong key protection, token validation, access controls, monitoring, and availability planning.
What is an identity broker?
An identity broker sits between one or more identity providers and the applications that rely on them. Instead of every application maintaining a separate federation relationship with every IdP, applications can trust the broker while the broker maintains upstream relationships.
During sign-in, a broker can:
- Validate an assertion or token from an upstream IdP.
- Reissue identity information in a form the application accepts.
- Translate between supported federation protocols, formats, or schemas.
- Convert incoming attributes into consistent downstream claims.
- Apply rules for attribute release.
- Route users to different IdPs based on organization, domain, or policy.
Not every broker translates protocols. Some use the same protocol on both sides but provide claim normalization, routing, or centralized trust management.
Identity brokerage versus IAM connector brokerage
Identity brokerage is a runtime federation function. The broker participates directly in a live sign-in and creates the assertion or token consumed by the application.
“IAM connector” is less precise. Depending on the product, a connector might synchronize directory records, provision accounts, query an API, or connect to a directory such as LDAP. Those activities can support identity management without participating in an interactive authentication transaction.
A single identity and access management platform may include brokers and connectors. The operational distinction is that a broker is in the sign-in trust path, while a synchronization or provisioning connector primarily moves identity and lifecycle data.
How does brokered sign-in work?
A typical brokered sign-in follows this sequence:
- A user opens an application.
- The application redirects the browser to the identity broker.
- The broker selects an upstream IdP or asks the user to choose one.
- The upstream IdP authenticates the user with its configured methods.
- The upstream IdP returns a protocol-specific response to the broker. In a SAML flow, the broker receives and validates a SAML response and assertion. In an OpenID Connect (OIDC) Authorization Code Flow, the broker receives an authorization code, exchanges it at the token endpoint, and then validates the ID Token.
- The broker verifies the expected issuer, audience, signature or other required protection, validity period, and protocol-specific controls.
- The broker maps the upstream subject and approved attributes to downstream claims.
- The broker creates and protects a new downstream assertion or token as required by the selected protocol.
- The application validates the broker-issued response, creates a session, and applies its authorization rules.
This creates two distinct trust relationships: one between the upstream IdP and broker, and another between the broker and application. A valid upstream response does not remove the application’s responsibility to validate what the broker issues.
Who authenticates the user, issues tokens, maps claims, and grants access?
The parties have separate responsibilities, even when one platform performs several roles:
- Upstream identity provider: Authenticates the user and issues the original response.
- Identity broker: Validates the upstream response, maps approved identity information, and usually issues the downstream assertion or token.
- Application or relying party: Validates the broker-issued response and decides what the user may do in the application.
The broker can transform a group, role, or authentication-context claim, but it should not be treated as the final authority for every application permission. The application remains responsible for its authorization policy and for rejecting assertions or tokens that fail validation.
When do you need an identity broker instead of direct federation?
An identity broker becomes useful when organizations need to connect multiple identity providers and applications, accommodate different federation requirements, or reduce repeated trust configurations.
Direct federation is usually simpler when the identity provider and application support compatible protocols, agree on identifiers and claims, and can maintain a secure trust relationship without an intermediary.
Common situations where identity brokerage helps
- Mergers and acquisitions: Employees from separate organizations need access to shared applications while their identity providers remain independent.
- Partner access: External users authenticate through different identity providers, but applications need a consistent federation relationship.
- Protocol compatibility: An identity provider and application require different federation protocols or profiles that a supported broker can connect.
- Claim standardization: Applications need consistent identifiers, roles, or attributes from different identity sources.
These are architectural use cases, not reasons to deploy a broker automatically. When direct federation is compatible and manageable, it usually introduces fewer dependencies.
Identity broker vs. direct federation
The following comparison helps determine when direct federation is sufficient and when introducing a broker may be justified.
| Decision factor | Direct federation is usually suitable when | A broker may be justified when |
|---|---|---|
| Protocol compatibility | The IdP and application support the same federation protocol and profile | The endpoints require different supported protocols, formats, or claim schemas |
| Integration scale | There are few IdP-to-application relationships | Many applications, business units, or partner IdPs would otherwise require repeated point-to-point configuration |
| Claim design | Applications can consume the IdP’s identifiers and attributes directly | Applications require normalized subjects, group names, roles, or authentication context |
| Trust management | Each application can manage metadata, certificates, and key rotation safely | A common trust boundary reduces duplicated configuration and operational work |
| Policy | Application-specific controls are sufficient | Central routing, attribute-release, or federation policy is required |
| Availability | Removing intermediaries is a priority | The organization can operate the broker as a critical sign-in dependency |
The trade-off is centralization. A broker can reduce connection sprawl, but it can also observe federation activity and issue trusted downstream assertions. It needs strong administrative controls, monitoring, key protection, and recovery planning; centralization is not automatically more secure.
Key takeaway: Use an identity broker when multiple IdPs, incompatible federation requirements, or repeated trust configurations create a meaningful integration problem. Prefer direct federation when existing systems are compatible and adding a broker would introduce complexity without a clear benefit.
How do you choose protocols and map identity claims?
Protocol selection should follow the capabilities of the IdP, broker, and application. Do not treat SAML, OIDC, OAuth, and LDAP as interchangeable technologies.
Where SAML, OpenID Connect, OAuth, and LDAP fit
- Security Assertion Markup Language (SAML): An XML-based federation framework commonly used for browser single sign-on between an IdP and a service provider. SAML defines assertions, metadata, identifiers, bindings, and trust relationships. See the OASIS SAML 2.0 Technical Overview.
- OpenID Connect (OIDC): An authentication protocol built on OAuth 2.0. It provides an ID Token containing claims about the user and authentication event, and can retrieve additional claims through the UserInfo endpoint. Clients must validate ID Tokens as specified in OpenID Connect Core.
- OAuth 2.0: An authorization framework used to grant scoped access to protected resources. An OAuth access token alone should not be treated as proof that an application authenticated a user; OIDC supplies the authentication layer for that use case.
- Lightweight Directory Access Protocol (LDAP): A directory access protocol with authentication and transport-security mechanisms such as bind operations, SASL, and TLS. LDAP can support directory lookup or credential validation, but it is not a browser federation protocol equivalent to SAML or OIDC. See RFC 4513.
Before selecting a broker, confirm the exact profiles and flows supported on both sides. Broad claims of “SAML support” or “OIDC support” do not establish compatibility with every binding, signing option, claim format, or application behavior.
Check identifiers, groups, and attributes before passing them to applications
Account linking should begin with a durable subject identifier. Where the protocol and application allow it, use the combination of the issuing authority and its subject identifier. Do not assume an email address, username, or display name will never be renamed or reassigned.
Once account identity is stable, map only what the application needs:
- Define the authoritative source for each role, group, and entitlement.
- Specify whether comparisons are case-sensitive.
- Normalize names and formats deliberately rather than relying on implicit conversion.
- Test how the application handles missing, empty, duplicated, or unexpected values.
- Test users with many group memberships to identify product-specific size or omission behavior.
- Document whether an existing account may be linked automatically or requires administrative approval.
- Avoid releasing profile or organizational attributes that the application does not require.
Claim transformation must preserve meaning. An upstream group named Finance, for example, should not become an administrator role because of a broad or ambiguous mapping rule.
What should you configure before connecting an identity broker?
Treat upstream and downstream connections as separate security configurations. For each side, document and verify:
- The exact issuer or entity identifier.
- Redirect URIs or SAML Assertion Consumer Service (ACS) URLs.
- Registered audiences and recipient values.
- Signing, verification, encryption, and decryption keys.
- Metadata or discovery endpoints.
- Accepted algorithms and protocol flows.
- Assertion or token lifetimes and permitted clock skew.
- Authentication-context requirements, where applicable.
- Certificate and key-rotation procedures.
- Logout and session behavior.
Set up trust between the broker, identity providers, and applications
The broker must verify the upstream IdP, and the application must independently verify the broker. Record which entity owns each trust relationship, which keys are active, and how metadata and certificates are updated.
Do not rely on a successful administrator sign-in as proof that trust is correctly configured. Test the expected validation failures as well as the happy path.
Test token validation, sessions, and failed sign-ins
Use a test matrix that includes:
- A normal sign-in by an existing user.
- First sign-in by a new user.
- A disabled or deleted upstream account.
- Removal of a required group or role.
- Missing and malformed claims.
- An expired or not-yet-valid assertion or token.
- A wrong audience or recipient.
- An invalid signature or unknown signing key.
- Upstream and broker key rollover.
- An unavailable upstream IdP.
- An unavailable broker.
Define the expected result for each test. In particular, determine whether access is denied immediately after an account or group change or only after an existing application session expires.
What security and availability risks should you assess?
Because a broker can issue trusted downstream assertions and observe federation activity, treat it as a high-value security and availability dependency. NIST SP 800-63C-4 addresses controls including assertion validation, audience restriction, replay protection, key storage, and key rotation.
Security controls should include:
- Secure storage and controlled use of signing and decryption keys.
- Authenticated key rotation with a tested overlap and rollback process.
- Strict validation of issuer, signature, audience, recipient, and validity time.
- Replay protection and validation of state or nonce where the protocol uses them.
- Exact registration of redirect and callback locations.
- Minimal release of identity attributes.
- Least-privilege access for broker administrators.
- Multi-factor authentication for privileged administration.
- Logs that connect upstream and downstream events through correlation identifiers.
- Monitoring for validation failures, configuration changes, and abnormal issuance activity.
Protect signing keys and limit access to identity attributes
A compromised signing key or privileged broker account can affect every application that trusts the broker. Limit access to key-management functions and administrative configuration, and release only the attributes required by each downstream application.
Plan for broker outages and changes to upstream providers
Availability planning must distinguish existing sessions from new sign-ins. A broker outage may block new authentication without immediately ending sessions maintained by downstream applications. The outcome depends on session duration, assertion or token lifetime, refresh behavior, and application-specific checks.
Document the expected behavior for upstream IdP failure, broker failure, network isolation, planned maintenance, certificate expiry, and provider metadata changes. Recovery procedures should restore configuration and keys without accidentally creating a new issuer or subject namespace.
Why is a brokered sign-in failing?
Start by identifying which hop failed: application to broker, broker to upstream IdP, upstream IdP back to broker, or broker back to application. A browser error page often shows where the process stopped, not which component caused the original problem.
Check redirects, protocol settings, token validity, and claim mappings
Use this diagnostic order:
- Record the timestamp, affected user, application, upstream IdP, and available correlation IDs.
- Confirm that the browser reached the expected endpoints without a redirect loop.
- Compare configured redirect URIs or ACS URLs with the actual request and response.
- Verify issuer, entity ID, audience, recipient, and client identifiers character for character.
- Check the signature and confirm that the recipient has the active verification key.
- Inspect expiration, not-before time, and clock synchronization.
- For OIDC flows, validate state and nonce handling where applicable, and confirm the authorization-code exchange succeeds when that flow is used.
- Compare the incoming identity claims with the broker’s outgoing claim set.
- Confirm that the subject links to the intended application account.
- Verify account status, required groups, and application-side authorization rules.
- Repeat the path with a controlled test user and capture logs from each component.
If authentication succeeds at the upstream IdP but the application denies access, focus on the broker’s validation and mapping logs, then the application’s token validation and authorization logs. If the broker never receives a valid upstream response, investigate the upstream trust configuration before changing downstream claims.
How does Scalefusion OneIdP support SAML identity federation?
Organizations may need to retain an existing SAML identity provider while controlling access to supported business applications from managed devices.
Scalefusion OneIdP supports configuring an external SAML 2.0 identity provider as an authentication source. Administrators can also configure SSO for supported SAML-enabled applications and apply managed-device access conditions, subject to the documented prerequisites.
This provides a relevant implementation path for organizations evaluating SAML identity federation. It should not be interpreted as universal protocol translation or compatibility with every identity provider and application.
Explore Scalefusion OneIdP to assess its fit for your organization’s requirements.
FAQs
1. Is an identity broker the same as an identity provider?
No. An identity provider authenticates a user and asserts the result. An identity broker mediates between an upstream identity system and a relying application, often validating one artifact and issuing another. A product can perform both roles, so determine its responsibility in each configured trust relationship.
2. Does an identity broker decide what a user can access?
Not necessarily. A broker can deny sign-in, apply federation policy, and map groups or roles. The downstream application commonly makes the final authorization decision using those claims, its local roles, and resource-specific policy. Incorrect claim mappings can therefore authenticate a user successfully while still granting too much or too little access.
3. Can an identity broker work with an identity provider that does not support SAML or OpenID Connect?
Possibly. The identity source must expose an interface that a supported adapter, custom integration, or intermediary can consume securely, and the broker must be able to produce a federation method accepted by the destination. An LDAP-backed directory, for example, may require an IdP or adapter before it can participate. Verify compatibility and the resulting trust model for the specific systems rather than assuming a custom connection is possible.
4. Can an identity broker prevent users from reaching a SaaS application outside a secure network path?
Not by itself. Routing sign-in through a broker can support authentication-time checks, but it does not prove that subsequent traffic between the device and the SaaS application follows an enforced network path. That requires separate controls, such as application access restrictions and an appropriate network or proxy architecture.