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. 
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.