OpenID Connect

Updated January 2nd 2018

Note: The old site, has now been removed. Our new site is now live and supports OpenID Connect as well as OAuth2 (with some restrictions). You need to migrate your site if it still uses

The problem with OAuth2

Despite being used by Facebook, Google, Twitter and others as a means to "log in" or authenticate with other web applications, OAuth2 is NOT an Authentication protocol! It is designed for a user to give permission for a site to access their data i.e. for Authorisation.

Fundamentally, OAuth2 does not permit the relying web application to require authentication (in many cases, a simple "OK" button is all the user sees) and even if the user was authenticated, the calling site has no feedback mechanism to know that authentication has taken place, when that occurred and what sort of authentication took place.

It is also a very permissive protocol which defines very little, leading to each adopter implementing it in different ways and requiring plugin authors to create many different classes to handle each variation.

So why is it used?

In part, people had misunderstood OAuth2 but also, it was seen as a much simpler way of getting Authentication compared to its main "rival" OpenID, a richer but much more complex system.

Simplicity drove adoption and OpenID was left behind.

So what does OpenID Connect do?

OpenID Connect fixes the main problems with OAuth2 while retaining much of the existing protocol. It is largely backwards compatible with OAuth2 depending on the exact implementation.

It adds the ability to request an authentication be carried out in a certain way, it responds with information that tells the relying party what took place and uses digital signatures so that the relying party can make use of this information and prove that it came from the identity server they expected.

It specifies various "standard" scopes and user data field names that OAuth2 allowed providers to define. It does allow these to be extended, although the core part is the same across all providers.

OpenID Connect also specifies a number of flows both the same as and also in addition to those specified by OAuth2. This allows, for instance, an instant response from the identity server when a user has authenticated and/or an authorisation code that the relying party can use to obtain an access token.

OpenID Connect adds discovery and metadata as an optional system that allows a plugin to configure its own endpoints by querying the identity server.

It also defines an optional dynamic registration function that allows customers to sign up electronically with an identity provider.

How can I implement it?

PixelPin now supports OpenID Connect, using the Identity Server library.

If you are creating a new system, you simply need to find an OpenID Connect plugin and enter the basic settings required. When using .Net, for instance, the plugin, provided by Microsoft, can be configured with no PixelPin specific class and only 6 configuration settings (PixelPin URL, client id, secret, Redirect URI, response type and authentication type for the site).

If you already use an OAuth2 plugin, it might work on the new site with changes only made to the endpoint URLs (where it connects to) but will not have any more functionality than before. In most cases, some other changes will need to be made, most likely to the scope parameter, which will probably need to include "openid" as well as any other scope. Ideally, you would look at replacing the OAuth2 plugin with an OpenID Connect version (the existing plugin might already support both protocols), in which case, you get better security and in some cases, higher performance since the handshake is reduced.