It’s no secret that OAuth2 and OpenID Connect are gaining in popularity. It seems that all of our customers are in the process of rolling out OAuth2 and OpenID Connect, or are thinking about it. But how can these newer protocols play nicely in your enterprise if you already have a SAML2 or WS-Federation infrastructure? The answer is an identity broker (also known as a federation proxy).

What is an Identity Broker / Federation Proxy

An identity broker (or federation proxy) accepts request from a relying party and proxies them to an identity provider. At the highest level, it works like this; OAuth2 and OpenID Connect federation requests are sent to the broker. The broker proxies those requests to your existing SAML2 identity provider or WS-Federation identity provider. The federation response is then used to create a response to the original OAuth2 or OpenID Federation request.
Identity Broker / Federation Proxy

Optimal Federation and Identity Services (OFIS)

This architecture is supported out of the box by Optimal IdM’s on – premise solution, Optimal Federation and Identity Services (OFIS) as well as the hosted solution, The OptimalCloud. Using OFIS as an identity broker, the relying party can make authentication requests using OAuth2, OpenID Connect, SAML2, or WS-Federation. OFIS can then proxy those requests to other identity providers using OAuth2, OpenID Connect, SAML2, or WS-Federation.

OAUTH2 Used as an Authentication Protocol

Yes, OAuth2 is considered an authorization rather than an authentication protocol. But it is often used as an authentication protocol in reality. For the purposes of this discussion we will talk about it in the same vein as OpenID Connect, SAML2, and WS-Federation. Even if used strictly for authorization, authentication will still be required, and for that authentication there might still be the need to proxy to more traditional federation protocols such as SAML2 and WS-Federation.

Cloud Synchronization Requirements

Most identity broker solutions and vendors require the enterprise to synchronize their on premise users to the cloud, or create identities in the cloud. This leads to a lot of provisioning and privacy issues. This also not the best solution as the last thing you want to do is to create more identities in order to solve your identity issues. It doesn’t simplify your problems. If using Optimal IdM OFIS, no users need to be synced to the broker. If you are using another solution that will likely not be true.

There are subtle difference in how this works depending on the grant flow being used. For the access code and implicit OAuth2 this is pretty straight forward. When an OAuth2 access request is made to the broker, the user is forwarded to a federated identity provider to perform an authentication request. The response is then received by the broker and if properly validated, the OAuth2 response is forwarded to the application.

If the Resource Owner Password Profile is used, then the broker needs to proxy that OAuth2 request to the identity provider. If the identity provider does not support OAuth2, then WS-Trust could be used for proxying the authentication requests.

In the broker the claims received can be transformed to populate an OpenID Connect token or User Profile. But what if additional claims are needed? There are several ways to address that if there is an addition source of claims. But that is for another time.


  • The database in which all of your organization’s sensitive identity data is stored.
  • A digital ledger in which digital transactions are recorded chronologically and publicly.
  • Securely managing customer identity and profile data, and controlling customer access to applications and services.
  • The means of linking a person's electronic identity and attributes, stored across multiple distinct identity management systems.
  • A legal framework that sets guidelines for the collection and processing of personal information of individuals within the EU.
  • The policy-based centralized orchestration of user identity management and access control.
  • An authentication infrastructure that is built, hosted and managed by a third-party service provider.
  • A security system that requires more than one method of authentication from independent categories of credentials to verify the user's identity for a login or other transaction.
  • A global provider of innovative and affordable identity access management solutions. 
  • Managing and auditing account and data access by privileged users.
  • Tools and technologies for controlling user access to critical information within an organization.
  • An authentication process that allows a user to access multiple applications with one set of login credentials.