What is the difference between an identity broker and an identity provider?

An identity provider owns the credentials and authenticates users directly. A broker usually does not hold the credentials for federated users; it delegates authentication to upstream providers and translates the result for applications. Many products, including Monosign, can play either role depending on configuration.

Can an identity broker translate between SAML and OIDC?

Yes, protocol translation is one of the main reasons brokers exist. The broker can accept a SAML assertion from an upstream provider and issue an OIDC token to the application, or the reverse, so neither side needs to change what it speaks.

Does adding a broker weaken security?

It adds a component that must be protected, but in return it becomes a single enforcement point for MFA, risk policies, and auditing across all connections. Most organizations end up with stronger, more consistent controls than they had with scattered point-to-point federations.

Identity Broker

What is an Identity Broker?

An identity broker sits between applications and multiple identity providers, translating protocols so each side integrates only once.

Last updated: 15 July 2026

How an identity broker works

An identity broker plays both roles in a federation. Toward applications it acts as the identity provider they trust; toward upstream identity sources it acts as a service provider or relying party. When a user arrives, the broker decides which upstream provider should authenticate them, based on their email domain, an explicit choice screen, or policy, then forwards them there.

After the upstream provider authenticates the user, the broker receives the assertion, validates it, optionally enriches or remaps the attributes, and issues its own token to the application in whatever protocol the application speaks. This translation ability is the broker's core value: a legacy application that only understands SAML can accept users authenticated through a modern OIDC provider, and vice versa, without either side knowing about the other.

Why identity brokers matter

Without a broker, connecting M applications to N identity providers means M times N integrations, each with its own certificates, metadata, and quirks. A broker collapses that to M plus N: every application integrates once with the broker, and every provider connects once. That arithmetic matters enormously in B2B software, where each enterprise customer wants to bring their own identity provider.

Brokers also centralize governance. Attribute mapping, MFA enforcement, and session policy live in one place instead of being renegotiated per connection, and switching an upstream provider becomes a configuration change rather than an application rewrite. Mergers, acquisitions, and gradual cloud migrations all lean on this property.

Identity brokers in practice

Typical broker deployments include B2B platforms onboarding enterprise customers with their own IdPs, organizations bridging an on-premises directory era into a cloud identity era, and groups of companies that must share applications across separate identity domains. Home realm discovery, deciding which provider a given user belongs to, is usually driven by email domain rules with a fallback chooser screen.

Design care goes into trust and attribute hygiene: the broker must validate upstream assertions strictly, normalize attributes into a consistent schema, and apply its own MFA or risk policy when an upstream provider's guarantees are unknown. Monosign operates as both identity provider and service provider over SAML and OIDC, which allows it to broker between applications and external or legacy identity sources.

Frequently asked questions

What is the difference between an identity broker and an identity provider?: An identity provider owns the credentials and authenticates users directly. A broker usually does not hold the credentials for federated users; it delegates authentication to upstream providers and translates the result for applications. Many products, including Monosign, can play either role depending on configuration.
Can an identity broker translate between SAML and OIDC?: Yes, protocol translation is one of the main reasons brokers exist. The broker can accept a SAML assertion from an upstream provider and issue an OIDC token to the application, or the reverse, so neither side needs to change what it speaks.
Does adding a broker weaken security?: It adds a component that must be protected, but in return it becomes a single enforcement point for MFA, risk policies, and auditing across all connections. Most organizations end up with stronger, more consistent controls than they had with scattered point-to-point federations.