What is OpenID Connect? How does it work?#OpenID Connect is an interoperable authentication protocol built on the OAuth 2.0 family of specifications. OpenID Connect uses straightforward REST/JSON message flows with a design goal of “making simple things simple and complicated things possible”. OpenID Connect is uniquely easy for developers to integrate, compared to any preceding authentication protocol.
What problem does OpenID Connect solve?#It lets mobile app and Web Application developers authenticate users without taking on the responsibility of storing and managing passwords in the face of an Internet that is well-populated with people trying to compromise your users’ accounts for their own gain.
What is the status of OpenID Connect?#Final OpenID Connect specifications were launched on February 26, 2014. The certification program for OpenID Connect was launched on April 22, 2015. Google, Microsoft, Ping Identity, ForgeRock, Nomura Research Institute, and PayPal OpenID Connect deployments were the first to self-certify conformance.
How does it improve security?#Public Key-encryption-based authentication frameworks like OpenID Connect (and its predecessors) globally increase the security of the whole Internet by putting the responsibility for user identity verification in the hands of the most expert service providers. Compared to its predecessors, OpenID Connect is dramatically easier to implement and integrate and can expect to receive much wider adoption. OAuth 2.0 or OpenID Connect. OAuth is only for delegation of Authorization to another entity. Often you have delegated your Authorization to a third-party when using mobile apps or Social Login. So, typically, when you go to a Web Application, you might use OpenID Connect to Authenticate yourself to the Web Application. The Web Application might then use OAuth to be Authorized to access some API on the back-end. In these typical implementations, the API service has no reason to know about the end-user, only the Web Application.
Easy for developers #Ease of use for developers was one of the primary goals. The feedback from the community is that OAuth 2.0 is ok! The basic ideas are well understood now. And there is plenty of sample code, sessions at programming conferences, and tools for developers to use. OAuth 2.0 is built on JSON / REST, so it’s aligned with this shift in development best practices.
Easy for domain administrators #If you are the system administrator for your domain, managing an authentication service for internal people and customers can be a challenge. Especially if multiple applications rely on this service. System administrators have a mantra: “Stay Calm and automate all the things.”
In this regard, OpenID Connect automates some of the manual work that authentication services of times past have relied on the admin to manage by hand. For example, discovery and client registration enable the web developers to do some of the legwork. Its better for everyone:
- the developer gets instant results (no waiting for the XYZ team to provision the agent…).
- And the system admin can review and modify as needed.
Supports better privacy controls for people #The client in OpenID Connect has a connection to the person. OpenID Connect defines a way for the client to ask the person to authorize the release of information to a third party. While more work needs to be done in this area, OpenID Connect is a good start, and paves the way for more complex authorization flows that can be defined in other OAuth 2.0 Profiles like User-Managed Access
Authentication-technology neutral#Never say OpenID Connect is an authentication protocol to an OpenID Connect expert… the knee jerk response is that OpenID Connect does not define the protocol for Authentication (look to FIDO to do this…). And it’s true… OpenID Connect defines everything around the Authentication except the authentication itself.
For example, OpenID Connect does define:
- how does the website look up where to send the person for authentication.
- how to register with the OpenID Provider, which is required to get information about the person who has been authenticated.
- how to to end the person’s session so that other apps will know that they need to re-authenticate the person.
As an example, In oxAuth, Gluu’s open source OpenID Connect Provider (OP), we support multi-step, strong authentication. Each domain can make a decision about the best authentication mechanisms to offer. With the plethora of authentication hardware, software, and SaaS services… having this kind of flexibility is awesome!
Extendable by complimentary profiles#OpenID Connect does a few things well, but it’s not the answer to everything. In fact, one of the goals of the effort was to achieve not the largest possible standard, but the smallest. Many efforts are underway to build on the strong foundation of OpenID Connect. How devices share sessions, how OpenID Providers and Relying Parties can collaborate using multi-party federation metadata, how OpenID Connect can be leveraged by an Authorization protocol like UMA all of these are examples of how well OpenID Connect can address challenges still unresolved in the industry.
Automates client registration#I’ve already mentioned how great this is for domain administrators. In fact, automating client registration is a requirement to scale. Many organizations today have a handful of SAML relationships. The difficulty in provisioning new SAML clients has been one of the barriers to adoption of SAML.
Provides an easy HTTP Discovery Mechanism#This is one of those subtle details that might be missed. OpenID Connect Discovery is darn useful. OpenID Connect Discovery enables a client to find out what URI’s the domain uses to publish the OpenID Connect APIs–where to register and where to request information about the person (user claims). OpenID Connect also sets a clear standard for other OAuth 2.0 Profiles. For example, in UMA, we use ./well-known/uma-configuration. All I can say is… nice work… it’s great when the simplest design is adopted!
Supports serious Cryptography#There are many trust models between domains on the Internet. Defense contractors need a high level of assurance. Your local sports club needs a very low Level Of Assurance. It is great that OpenID Connect supports a range of trust requirements.
Supports the complexity of today’s mobile / API ecosystem#Native applications–including not only Mobile Devices, but some incredibly powerful desktop applications–needed a better authentication infrastructure than previous web-centric SSO solutions provided. OpenID Connect has better support for a client collecting the credentials of a person. In some cases, if you are using a native application, and the browser pops up and asks you for your credentials… it’s a weird user experience. In some cases, the native app is collecting biometric data, generating a key, or providing other important contextual data that can be used to figure out if it’s necessary to authenticate the person. Interactive web authentication–where the person’s browser is re-directed to the home identity provider–is great for many use cases. But thankfully, OpenID Connect didn’t stop there in its core set of guidelines.
People are finally ready for change#It is very hard to change user behavior. Everyone knows passwords are bad. A recent Verizon study indicated that 80% of IT security breaches were the result of bad passwords. It took 9/11 for people to accept airline security. While thankfully nothing as horrible in the electronic security world has occurred, people experience death by a thousand paper cuts. I think if we offer a better alternative, people are finally ready to change their behavior to take advantage of it. OpenID Connect has no implementation for User Provisioning. But wait, why do we do User Provisioning? Generally, the goals of User Provisioning are:
- Create fresh users in the downstream application or directory based on values derived from the a user Profile and Claims (think Group assignments).
- Import users from the downstream application or directory in order to match them to existing users, or to create new users from the imported application or LDAP directory users.
- For an application or directory user that is affiliated with or ‘tied to’ an user, update the downstream user’s attributes when the user is updated.
- Deprovision the application user from the downstream application. This can take many forms; user disabled, user access permissions changed, user license pulled, etc.
But, most Applications do not require a User Provisioning. User Provisioning was done when there was no ability for to use a central user repository and before we had any widely adopted external Authentication. Applicaitons need:OpenID Connect without performing User Provisioning to the Application level.
Typically, the Application, only needs some assurance that the user is has Authenticated. The OpenID Connect Provider provides a “sub” claim which is guaranteed to be Unique for that Provider. The WEB Application can use the “provider-sub” combination as a identifier so that when that same user returns to the WEB Application, the user can be identified.
More Information#There might be more information for this subject on one of the following:
- [#1] - 10 Reasons Why OpenID Connect will be ubiquitous for domain authentication - based on information obtained 2013-04-10