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 interface for discovery#This is one of those subtle details that might be missed. OpenID Connect Discovery is darn useful. It 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’s 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.
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