More than a decade ago, every website had to have a login process and database for users’ accounts and credentials. This approach had two main problems: the user was continually having to sign up and create new accounts on each website they visited (as well as remember all their credentials) and, in instances of online retail, businesses found that customers would fill shopping carts and then not complete transactions because they had to create an account.
The security and administrative problems of maintaining separate user databases were challenging. The solution to these problems was a feature that could authenticate users across multiple sites. OpenID enabled this to happen when it was introduced in 2005.i It allows someone to use an existing account to sign in to multiple websites without creating separate passwords and identities for each, facilitating single sign-on. On the service provider/vendor side, webmasters no longer needed to provide their ad hoc login systems.
OpenID is intended to allow users to perform actions without authenticating credentials or establishing blanket permissions to clients or third parties. This framework enables countless transactions, saving users and developers immeasurable amounts of time. In this article, we’ll discuss OpenID and OpenID Connect in your business: what they are, the differences, benefits, framework, and steps to implement.
Explaining OpenID & OpenID Connect
OpenID and OpenID Connect are open standard, decentralized authentication protocols that allow websites and authentication services to securely exchange information in a standardized way.i It allows a user to use an existing account to sign in to multiple websites without creating separate passwords and identities for each.
The OpenID standard is a framework for the communication that must take place between the identity provider and the OpenID acceptor. An extension to the standard facilitates the transfer of user attributes, such as their name and email address, from the OpenID identity provider to the relying party.
OpenID was created for federated authentication to let a third-party authenticate users through accounts they already possessed. “Federated” is crucial because the objective of OpenID is that any provider can be utilized except whitelists. Thus, users don’t need to pre-select or negotiate with providers to allow them to employ any other account they have.
OpenID Connect, introduced in 2014, provided additional benefits by allowing end-users to log in once and access multiple, disparate resources on and off the web. The end goal of OpenID Connect is the same as Open ID: to allow a user to log in just once so they can access numerous web resources without needing to provide multiple authentication credentials. However, it does not specify one method of authenticating identity; some sites use passwords and some may use techniques like smart cards or even biometric means to verify a user’s identity.
As of March 2016, more than one billion OpenID-enabled accounts existed on the internet. More than one million sites have integrated OpenID support, including Flickr, Google, Amazon.com, Microsoft, Novell, Universal Music Group, VeriSign, Yahoo!, IBM, and PayPal.
How are OpenID & OpenID Connect different?
OpenID Connect performs many of the same tasks as OpenID, but in a way that is API-friendly and usable by native and mobile applications. Integration of OpenID requires an extension; in OpenID Connect, authentication capabilities are integrated within the protocol itself.
OpenID Connect standardizes scopes, endpoint discovery, and dynamic registration of clients, making it easier for code construction that lets the user choose between multiple identity providers.
Framework of OpenID
OpenID provides a framework between two websites. The website accepting the user authentication is known as the OpenID acceptor, or the relying party.
In this login process, the user’s password is only given to the first website (the “identity provider” or “IdP”). This website confirms the user’s identity to other websites that accept OpenID authentication. The advantage for the user is that other than the provider, no website ever sees their password. The OpenID acceptor trusts the identity provider. This reduces the chances that an insecure website compromises a user’s identity.
For developers and app builders, the benefits of OpenID and OpenID Connect are numerous.
Developers can authenticate users across websites and apps without having to own and manage password files. For the app builder, OpenID securely answers the question: “Who is the person currently using the browser/app that is connected to me?”iii
OpenID: Crucial for Your Business
OpenID is a way of identifying a user no matter the websites the user visits. Through it, users can associate information with their OpenID, like their name and email address. Then the user chooses how many websites get to see their data, meaning that websites can take advantage of OpenID but are not asking for the same information repeatedly.
OpenID also simplifies the process of signing into website accounts because it remembers one username and one password. Doing so reduces “friction” for the end-user by no longer requiring them to provide login credentials for every site they visit.
OpenID Security
OpenID is just as secure as what users rely on now to authenticate into various web accounts. Currently, most sites provide a reset service to change users’ passwords if they’ve been forgotten. If someone hacks into a user’s email account, they can only do damage if they accessed a user’s OpenID username and password.
Are users entrusting their entire identity to a single authentication solution?
Yes and no. If users prefer, they can create multiple OpenIDs, each of which may contain bits of their personal information but doing so squanders the simplicity of having only one username and password tracked.
Steps for Using OpenID
- A user wants to access a resource protected by the resource party.
- The resource party asks the user for OpenID.
- The user enters the OpenID that is received by the resource party.
- The resource party identifies the OpenID provider and initiates a trusted association.
- The OpenID provider generates and returns keys and the association handle.
- The request is redirected to the user for authentication.
- The user enters credentials received by the OpenID provider.
- The OpenID provider validates the user and redirects the user back to the resource party with a signed assertion.
- The user presents the signed assertion to the resource party.
- The resource party validates the assertion and creates a session for the user.
OpenID allows users to perform actions without authenticating credentials or establishing blanket permissions to clients or third parties, reduces friction at the point of sale, and enables countless transactions while saving immeasurable amounts of time for everyone in the process.
i. What is OpenID (OpenID Connect)? – Definition from WhatIs.com
ii. OpenID Authentication 2.0 – Final
iii. OpenID Connect FAQ and Q&As