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

AuthN, AuthZ & User Info Flow in OpenID Connect:

1. The User requests access to a resource from the service provider / Relying Party
2. The Relying Party (RP) returns a list of supported Identity Provider / OpenID Provider (OP) (e.g.  Login with Amazon or Google+ Sign-In)
3. The User selects their preferred Identity Provider
4. The RP (Client) sends a request to the user selected OpenID Provider (OP).
5. The OP authenticates the End-User and obtains authorisation. (The OP renders their own authentication challenge page)
6. The OP responds with an ID Token and usually an Access Token.
7. The RP can send a request with the Access Token to the UserInfo Endpoint. (The OP usually renders a form informing the user what information will be shared)
8. The UserInfo Endpoint returns Claims about the End-User.

OpenID Provider

To enable OpenID Connect trust is pre-established between the OpenID Connect client and server. Libraries are required for the Relying Party and the Identity Provider / OpenID Provider. The following are examples of common OpenID Connect Providers (IdP):

• Amazon
• Google
• PayPal

The OpenID Provider provides the authentication challenge if necessary and informs the user of the attributes to be shared. As trust is pre-agreed between the RP and the OP the OP can provide documentary links to the RP’s privacy policies. For example Login with Amazon mandates a like to a Privacy URL which links to the relying party’s privacy policy.

Relying Party

Each Relying Party maintains a list of its supported Identity Providers. It is normal for each OpenID Provider to supply the branded imagery for the login button, for example Login with Amazon works by providing third-party websites and mobile apps (clients) with a recognisable login button that users click to sign in with their Amazon credentials.

JSON Web Token

The Authentication result is returned in an ID Token. The primary extension that OpenID Connect makes to OAuth 2.0 to enable End-Users to be Authenticated is the ID Token data structure. The ID Token is a security token that contains Claims about the Authentication of an End-User by an AuthZ Server when using a Client, and potentially other requested Claims. The ID Token is represented as a JSON Web Token (JWT). The JWT contains all the relevant information for the Claim. ID Tokens MUST be signed using JWS and optionally both signed and then encrypted using JWS and JWE [respectively, thereby providing authentication, integrity, non-repudiation, and optionally confidentiality.

Mobile Apps

The SAML Identity Broker Service uses the SAML SSO Web Profile which is limited to web traffic only. OpenID Connect broker can support more than just Web traffic and can therefore be used for mobile apps (e.g Mobile Connect) and other home entertainment systems potentially including eUICCs.