Identity Broker Service in OpenID Connect: Supporting Multiple Identity Providers & Service Providers

August 4, 2014October 1, 2014 mustnotgrumbleLeave a comment

This blog is part of a series comparing the implementation of identity management patterns in SAML and OpenID Connect:

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

Continue reading “Identity Broker Service in OpenID Connect: Supporting Multiple Identity Providers & Service Providers” →

Comparison of OpenID Connect with OAuth2.0 & SAML2.0

July 23, 2014 mustnotgrumbleLeave a comment

The following is a high level feature comparison between OpenID Connect 1.0, OAuth 2.0 & SAML 2.0

OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 protocol. It allows Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OAuth 2.0 focuses on client developer simplicity while providing specific authorisation flows for web applications, desktop applications, mobile phones, and living room device
SAML 2.0 provides a standard for exchanging authentication and authorisation data between security domains using an XML-based protocol which uses security tokens containing assertions to pass information about a principal between an identity provider and a service provider.

Usage:

OpenID Connect allows a user to authenticate to an on-device App, a service or a site using an identity established with an Identity Provider (IdP).
Integration of OAuth 1.0 and OpenID 2.0 required an extension. In OpenID Connect this OAuth 2.0 capability is built into the protocol itself.
Mobile apps don’t have access to the HTTP POST body which is required in SAML to post the token back to the Service Provider. As such SAML 2.0 has a native app (yes you could use a blended app) limitation

APIs:

All three have extensive libraries (OAuth libraries, OpenID Connect libraries, simple SAML PHP library)
OpenID Connect is REST based encapsulating JSON Web Tokens while SAML is XML based
OpenID Connect performs many of the same tasks OpenID 2.0, OAuth2.0 and SAML, but does so in a way that is standardised and API-friendly.
OpenID Connect can also be extended to include more robust mechanisms for signing and encryption

Tokens (Signing & Encryption):

OpenID Connect is REST based encapsulating JSON Web Tokens which do not only sign the payload (does not encrypt it)
SAML is XML based and supports signing & encrypted certificates
OAuth 2.0 uses bearer token (similar to cookies) which do not require a bearer to prove possession of cryptographic key material (proof-of-possession). Risks for the enterprise.

Feature Comparison:

OpenID Connect 1.0:

✔ SP & IdP Initiated Login
✔ High Security Identity tokens (JSON Web Token)
✔ Collects user’s consent before sharing attributes
✔ Token contains user identity information
✔ Distributed & Aggregated Claims
✔ Dynamic Introductions (client discovery & on-boarding)
✔ Session Timeout (future)

OAuth 2.0:

✔ SP & IdP Initiated Login
✘ High Security Identity tokens (uses bearer token which have no proof of possession)
✔ Collects user’s consent
✘ Token contains user identity information
✘ No Distributed & Aggregated Claims
✘ No Dynamic Introductions (client discovery & on-boarding)
✘ No Session Timeout

SAML 2.0:

✔ SP & IdP Initiated Login
✘ Does not support embedded applications
✔ High Security Identity tokens (e.g. X.509)
✘ Not Responsible for collecting user’s consent
✘ Token contains user identity information
✘ No Distributed & Aggregated Claims
✘ No Dynamic Introductions (client discovery & on-boarding)
✘ No Session Timeout

Open ID Connect and GSMA Mobile Connect

July 10, 2014 mustnotgrumble1 Comment

OpenID Connect (final specs launched Feb 2014) is an interoperable authentication protocol based on the OAuth 2.0 family of specifications. It uses straightforward REST/JSON message flows with a design goal of “making simple things simple and complicated things possible”. OpenID Connect lets developers authenticate their users across websites and apps without having to own and manage password files. OpenID Connect has been implemented worldwide by Google, Microsoft, Deutsche Telekom, salesforce.com, Ping Identity and others.

The GSMA Mobile Connect service is a mobile operator collaborative initiative to implement a mobile phone number-based authentication mechanism on top of OpenID Connect. With Mobile Connect the MNO creates a token which is then shared with vendors to verify the customer. The token can be tied to an email address or another user identifier but the GSMA views the MSISDN as the unique identifier for identity aggregation and vendor integrations will be based around mobile phone number. Don’t mention Vodafone360!

The OpenID Connect is built as a simple identity layer on top of the OAuth 2.0 protocol. It allows clients to verify the identity of the end-user based on the authentication performed by an authorisation server. OpenID Connect supports identity attributes by obtaining basic profile information about the end-user in an interoperable and REST-like manner. OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps which allows the mobile internet device to act as a local authorisation server authenticating applications with the identity provision held within the secure SIM card.

OpenID Connect differs from OAuth which is an access granting protocol and as such has no definition of identity. As an example Facebook extends OAuth with what it calls a ‘signed request’ in order to provide identity on top of authorisation. The ‘signed request’ is conceptually analogous to OpenID Connect’s JWT “ID Token” which works with multiple identity providers by using the IETF JSON Web Signature (JWS). In order to be interoperable Open ID Connect provides a standard way of requesting and responding claims for which Open ID Connect has defined a standard scope, RESTful granular methods for request objects & claims and a JSON based “ID Token”.

Open ID Connect supports identity providers such as Google+ Sign-In and IdPs on to the mobile internet device. In this later case the mobile phone can act as self issuing identity provider (e.g. Janrain). It is in this space that GSMA Mobile Connect will feature strongly supporting both the large Identity Provider (e.g Deutsche Telekom‘s support for OpenID for its Business Marketplace to act as an OpenID 2.0 provider to support single sign-on for applications) and the customer delegated model with identity stored and provided from the phone.