Category: OpenID Connect

Why the Future of Identity is OpenID Connect and not SAML

mustnotgrumbleLeave a comment

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

Future of Identity Federation is OpenID Connect

Identity management is an enabler for networked services whether web browser, mobile or smart-tv applications or the internet of things. The increase in services will create an increase in passwords without mechanism for sharing & trusting identities. eGovernment services require a higher level of identity verification than the social authentication capabilities of Twitter & Facebook connect. The future of eGovernment Identity is an interoperable authentication and authorisation capability that can support higher levels of identity verification.

The importance of interoperability amongst identity solutions is that it will enable individuals to choose between and manage multiple different interoperable credentials. Futhermore service providers will choose to accept a variety of credential and identification media types. “Identity Solutions will be Interoperable” is a guiding principle of the US National Strategy for Trusted Identities in Cyberspace (NSTIC) which is a White House initiative for both public & private sectors to improve the privacy, security, and convenience of online transactions.

SAML is insufficiently interoperable to be the future standard for identity management federation. SAML is limited in its ability to support mobile & smart-TV applications and requires the implementation of a complex Broker Service in order to support multi-service provider & multi-IdP use cases.

OpenID Connect will most likely supersede SAML for all eGovernment externalised identity management. OpenID Connect is a lightweight identity verification protocol built on top of modern web standards (OAuth 2.0, REST and JSON) superseding OpenID 2.0. OpenID Connect allows a service provider (Relying Party) to select between a variety of registered or discovered identity providers. OpenID Connect can satisfy all of the SAML use cases but with a simpler, JSON/REST based protocol.

SAML OpenID Connect Comparison
SAML 2.0 & OpenID Connect comparison

Continue reading “Why the Future of Identity is OpenID Connect and not SAML” →

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

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

OpenID Connet without Hub

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

OpenID Connect Simple Sequence Diagram

mustnotgrumble2 Comments

The OpenID Connect protocol, in abstract, follows the following steps.

  1. The RP (Client) sends a request to the OpenID Provider (OP).
  2. The OP authenticates the End-User and obtains authorization.
  3. The OP responds with an ID Token and usually an Access Token.
  4. The RP can send a request with the Access Token to the UserInfo Endpoint.
  5. The UserInfo Endpoint returns Claims about the End-User.

These steps are illustrated in the following diagram:

OpenID Connect Sequence Diagram

OpenID Connect & SAML nomenclature

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

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

NASCAR problem in authorisation server selection

mustnotgrumbleLeave a comment

An aim of OpenID Connect is to solve the problem of death by a thousand passwords by allowing the user to select their  identity provider including ones that the relying party has never heard of through Dynamic Registration. A problem of allowing the user to select their identity provider is that the authentication challenge page needs to show all the registered identity providers.

Nascar Problem

This means that this page becomes like the NASCAR problem. The NASCAR problem describes the jumble of branding icons on websites, e.g. 3rd party sign-in/login options or sharing buttons. It is dubbed the NASCAR problem because of these clusters of 3rd party icons/brands on websites resembles the collages of sponsorship decals covering NASCAR racing cars. It’s a problem because such clusters of icons/brands cause both visual noise and people to be confused, overwhelmed or unlikely to remember individual icons, especially as the clusters seem to grow with the introduction of new 3rd party identity/profile/social sites and services.

When using OSelect Identity ProviderpenID Connect, it’s likely that the client will both have buttons for popular servers as well as a text field for user entry of an email address or URL. (OpenID Connect does not directly solve the “NASCAR” problem).

How therefore to solve the NASCAR problem in OpenID Connect?

The client will need to either limit the number of registered authorisation servers supported by their service or provide a mechanism for selecting from a larger list of identity providers. Furthermore if the OpenID Connect Dynamic Registration capability is enabled a form field for the authorisation server’s URL needs to be provided as a last option below the existing identity providers.

Limiting the number of supported identity providers maybe easier for commercial sites. In a public sector / government scenario there may be legal reasons why the number of authorisation servers cannot be constrained. As a future example it may become necessary for a government service provider to support all retail banks operating in that country acting as authorisation servers (e.g. PAYM in the UK) and all the mobile network operators acting in that country (e.g. MobileConnect). In this example there may be more that 50 different authorisation providers and the user may have an existing registration with multiple identity providers. It is here that presentation of identity provider is important and mere alphabetic listing maybe insufficient.

Remote Control Soufflés: Challenge of M2M Authentication & Authorisation and Mobile data offloading

mustnotgrumbleLeave a comment

Some M2M devices will always connect to the internet using a fixed network connection / Wifi and others will always connect using a mobile network connection using an eUICC but there will be some that will offer both wifi and mobile network. It is these devices that will need to support wifi offloading where possible.  It is for these devices where providing a standard API gateway and AuthN & AuthZ capability will be most complex.

For example, my oven is always positioned in my kitchen and connects to the wifi network to allow me to view inside by a mobile app so that I don’t have to open the oven door during the fifteen minutes a soufflé takes to rise that would cause the temperature to change and my soufflé to collapse. This way I can inspect and control the temperature remotely. It also mean I have an excuse to check my phone during boring dinner parties. Only my app is paired to the oven so only I am authenticated and authorised to remotely check on my soufflé thus there is no potential risk of a malicious guest could accessing my oven app and destroy the soufflé by changing the temperature.

Remote viewing would decrease flop rate
An M2M oven with embedded camera would decrease flops

The majority of my home m2m devices will be static devices, I rarely travel with my oven, and these will in the majority of cases be Wifi enabled. Unfortunately I cannot guarantee wifi coverage throughout my architect’s ivory tower so some mobile internet devices will need to connect over 3G/4G (for example the BBQ in the lower field). The problem for my oven and BBQ manufacturers is that they would need to support both Wifi and the GSMA standard for M2M / smart device SIMs (eUICC). It would then be responsibility of the m2m device to support wifi offload where available.

Authorisation may be necessary when the function of the device is shared amongst a group with one or many people acting as the super administrator. If I sell my oven all of my authentication and authorisation permissions have to be removed from the M2M device but as I will likely buy a new oven with more soufflé capacity I would like to keep my existing settings.  Furthermore if my soufflé skills increased I may take a job in Paris and would need to reregister my oven’s eUICC or wifi connection. In this case I would definitely want to keep all of my authorisation permissions and maybe grant further permissions for all the extra soufflés I’d be baking.

Device resale and device portability are supported by the eUICC specification as they are necessary for widespread adoption of M2M devices. What is less supported is a common standard for AuthN & AuthZ that would allow me to keep my device preferences when I either move with or my devices or sell them and replace them with newer devices.

This is where OpenID Connect may be useful as it enables profile information on top of the authorisation model provided by OAuth 2.0. OpenID Connect 1.0 extends OAuth 2.0 so the client can verify claims about the identity of the end user, get profile information about the end user, and log the user out at the end of the OpenAM session. OpenID Connect also makes it possible to discover the provider for an end user, and to register client applications dynamically. OpenID connect services are built on OAuth 2.0, JSON Web Token (JWT), WebFinger and well-Known URIs.

It remains to be seen whether OpenID Connect will be integrated with the standards for eUICC as part of the GSMA Mobile Connect. Furthermore it will need to be supported by the wifi offloading devices (e.g. my BBQ’s manufacturer) as the standard for all M2M AuthN & AuthZ. It seems likely at first that device authorisation and later home M2M gateways will implement proprietary technologies and will maintain identity in individual walled gardens. My architecture ivory tower has a few of those too.

Open ID Connect and GSMA Mobile Connect

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.