This blog is part of a series comparing the implementation of identity management patterns in SAML and OpenID Connect:
- Identity Broker Service in SAML
- OpenID Connect AuthN & AuthZ
- Cross Domain Identity Patterns: Chained Federation & Service Broker
Identity Broker Service in OpenID Connect
In an earlier blog post (Identity Broker Service in SAML) described how to support connections between multiple service provides and multiple identity providers by building an Identity Broker Service. This service presents the user with a list of identity providers supported by the service provider and then forwards a <saml:AuthnRequest> to the appropriate identity provider. The broker then maintains this connection and returns a <saml:Response> from the identity provider back to the service provider. The service provider accepts the <saml:Response> and trusts the end user. In order to build this model using SAML the identity broker service requires development and deployment to the internet and the sharing of keys between all service providers and identity providers.
Using OpenID Connect the same function can be built without the need for an intermediary broker service. This is because in OpenID Connect is designed with the user being able to select their preferred identity provider. The Identity Provider, also known as the OpenID Provider, renders the authentication challenge and gains user approval before sharing user attributes. OpenID Connect performs authentication to log in the End-User or to determine that the End-User is already logged in. OpenID Connect returns the result of the Authentication performed by the Server to the Client in a secure manner so that the Client can rely on it, hence the Client is called Relying Party (RP).