Open ID Connect and GSMA Mobile Connect

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.

Cross Domain Identity Patterns: Chained Federation & Service Broker

Chained Federation allows access to multiple Service Providers to be granted to multiple trusted Identity Providers. The identity provider request access to the service provider via the Service Broker which authorises the request and forwards to the appropriate service provider based on the TargetURL. This is useful where an enterprise is providing multiple services to multiple customers (identity providers) and does not want to manage many to many relationships.

fed2

Advantages:
Externalise trust to external identity providers who bear cost of on-boarding users. User can choose their identity provider.

Requirements:
Agreed contract with identity provider.

Challenges:
In an enterprise implementation further data may be required to decorate the user and assign role or permission (see Mapped Federation)
The Service Broker needs to maintain the service provider targetURL and the service broker URL. In an enterprise implementation this is often best provided as a service.

Examples:
UK Government Gateway
3 Legged OAuth implementation (e.g. Twitter)

OAuth Terminology in SAML2

A Resource Server in OAuth is a Service Provider in SAML2

An Authorization Server in OAuth is an Identity Provider in SAML2

Thankfully a Client is a User

I still often say SPIL (SAML2.0 Service Provider Initiated Login) and IDIL (SAML2.0 Identity Provider Initiated Login) on a regular basis.  I find RSIL and ASIL harder.