What is an Identity Broker? - Everything you need to know

When building a software program, the technique of user authentication is one of the crucial elements that developers must consider. Given the growing inclination of end users to validate their identity via an existing social account, it is unsurprising that an increasing number of applications are incorporating the social login authentication mechanism. However, since the preferred social network likely differs from user to user, and SSO provider likely differs from company to company, it is crucial for the app in question to provide a broad selection of identity providers and authentication methods. Unfortunately, doing so usually implies that the provider must individually integrate and manage every integration and contract, several times over.

Integrating multiple Identity Providers directly within your applications is complex to maintain, time-consuming to set up, and hinders single sign-on of users – In other words, it does not scale. Luckily, this problem can be easily solved with the help of an Identity Broker.

This article tackles the definition of an identity broker and what identity brokering looks like in practice.

What does an Identity Broker do?

The term Identity Broker (IB) describes a web application that facilitates authentication between service providers and their configured Identity Providers.  By acting as a trusted intermediary service, an IB connects projects with different identity providers, so that developers do not have to bother with integrating them individually into their apps. With the help of its centralized way of managing identities, end-users have the option to create a new account by using the identity data acquired from several identity sources (such as Google, Facebook, Twitter, etc.). An IB may also allow you to link multiple external identity providers to one user account. Thus, the implementation of social logins, other alternate authentication methods and the configuration of individual login policies are made easier than ever.

It is common for organizations to integrate their applications with a cloud-based identity management platform (such as ZITADEL), which can broker to many different identity providers out of the box, usually based on protocols such as SAML, OIDC and OAuth. By relying on the identity provided by such pre-configured services, you have ensured a robust trust anchor for all your applications and devices.

Identity Brokering in Practice

With the theory out of the way, it is useful to see how identity brokering functions in practice.

Identity Brokering is generally used in both Business-to-Customer (B2C, CIAM) and Business-to-Business (B2B) use cases. For B2C businesses it is vital for vendors to offer different social identity providers, authentication methods and login policies to best fit the needs of their end-users. Vendors of B2B software may need to provide enterprise SSO by allowing login with the customer’s identity provider (eg, Azure AD) and tailor security policies to fit their customer’s requirements.

Alternatively, Identity Brokering can be used in Government-to-Business (G2B) as well as Government-to-Citizen (G2C) cases. The principle in these cases is the same as in the Business-to-X context, the role of the business is simply replaced with a government institution/agency (such as banks, legislatures, etc.). For instance, Australian users with a registered MyGovID may use this identity to access a range of government online services (such as student and health data portals), instead of having to rely on usernames and passwords.

Regardless of the use case, the process of identity brokering follows the same simple steps. As an example, let us imagine an organization called “Gladix” that uses ZITADEL as a broker:

The application of Gladix has Google pre-configured as an identity provider. Accordingly, their end-users will get the option to link their existing or new ZITADEL account with their Google account by clicking on the “Google” symbol on ZITADEL’s login screen. Upon doing so, ZITADEL will redirect the end-user to the login screen of Google where they must authenticate themselves and then, if successful, they are directed back to the previous page. Following this authorization, the end-user will be able to login into ZITADEL, and subsequently Gladix’s application, by using their Google identity.