The top three things, that people do not understand about OpenID Connect.
Misunderstanding 1: “We already got OAuth, so we don’t need OpenID Connect”
Great, that you have OAuth. If you have it long enough, you probably have a big API portfolio and have very likely come across the need to expose customer data, employee data or partner data. You need to expose the data so you wrote one or multiple APIs to deliver person attributes. The Person API – every company creates an API with data about the people it deals with. Sometimes this API is called a customer API, an employee API, a user API or a me API. This API delivers data about a person – not about any person – but just about the person that is currently logged in. This API delivers identity information, including the name, the email address and a profile picture. One aspect of OpenID Connect is the attempt to standardize this kind of API. In OpenID Connect this standardized API is called
Misunderstanding 2:“OpenID Connect is an authentication standard”
No. OpenID Connect is agnostic to the authentication mechanism you use. It does not prescribe how you have to authenticate a user. But having an authentication mechanism – any authentication mechanism in
Misunderstanding 3: “OpenID is a short form for OpenID Connect”
No. OpenID and OpenID Connect are separate standards – maintained by the same foundation and addressing a similar set of problems. OpenID is an older standard using proprietary technologies, so it is difficult to implement, often error-prone and incompatible. For this reason, it never found widespread acceptance. OpenID Connect is built on many web standards and best practices such as OAuth, JSON, TLS, JWT, JWS, JWE, JWK, JWA.
To understand OpenID Connect in-depth it helps to have a visualization of the Flows. In the new OpenID Connect Book, the OpenID Connect Flows are described as Sequence Diagrams.
In the book OAuth 2.0 you can find all the standard OAuth Flows, visualized as Sequence Diagrams.
