Authentication and Authorization go hand in hand. If you want to read more about OAuth 2.0 which helps in Authorization you can go through the link. (I would suggest reading my blog about OAuth 2.0 first you will get more idea about this topic.)
Let’s start with Why OpenID Connect was invented?
So before we even talk about OpenID Connect I will start with a really simple kind of authentication that happens on the web which is the simplest case which I will call Simple Login and sometimes its called Forms-based Authentication. This is like the simple example where you will have like simple form which has username and password or email and password where the user enters his credentials then it goes to backend and search happens whether these credentials are present in your database or not if yes that will be kind of stored in your cookies in application with session-id to keep track of user and then yes user is logged in. This is how authentication started on the web and we can still do this now also if we want.
But there was a bit of downside of doing this kind of authentication which I just described. So when you are doing authentication this way you are responsible for maintaining security and maintenance of the authentication system. So you have to be aware of security and there is quite a bit of maintenance involved in this making sure your authentication is still working.
So now OAuth 2.0 and OpenID Connect are becoming the industry best practices to solve these kinds of problems.
OAuth 2.0 was perfect for purpose of Authorization. It deals with permissions and scopes and solves the problem of Authorization very well. It’s very popular and lots of people use it. But what happened actually is People saw that OAuth 2.0 solves the problem of Authorization very well so they started using it for Authentication purposes as well by using some hacks on top of that. Which somewhat was not a good way because OAuth 2.0 was never built for the purpose of Authentication. It does not care about who the user is and there is no way of getting users’ information in OAuth 2.0 flow. OAuth 2.0 only deals with scopes and permissions.
People who built OAuth 2.0 realized that OAuth 2.0 works really well but it misses some layer that can solve the problem of Authentication as well. So they added OpenID Connect on top of OAuth. That’s how OpenID Connect was invented.
OpenID Connect is not actually a different protocol. It is layers added on top of OAuth 2.0.It just an extension of OAuth 2.0 to solve the problem of Authentication or to get some user’s information as well. When you log in to any website that website should get some information about the user right?
Now let’s see what OpenID Connect adds.
- ID token: OpenID Connect add something called ID token as in name it says Identification. It tells about the Identity of the user. The tokens contain all the necessary information which application wants.
- UserInfo endpoint for getting more user information: If we ever feel information in ID token is not sufficient there is UserInfo endpoint in OpenID Connect flow so we can always request for more information or get more user details.
- The standard set of scopes: A standard set of scopes to more specifically access resources.
- Standardized implementation: More Standardized implementation than OAuth 2.0.
Now let’s see OpenID Connect Flow on top of OAuth 2.0. (If you find this flow difficult to understand please go through my blog on OAuth 2.0 on the link.)
The flow is the same as OAuth 2.0 flow only thing gets added is Scope which is OpenID. Because of scope as OpenID now OpenID Connect flow will be executed on top of OAuth 2.0.
You (user or resource owner) clicks on button which is connect with google on yelp.com(Client). It gets redirected to accounts.google.com(Authorization server) with defined Redirect URL, Response type, and Scope. You enter your credentials and click enter. Now you will see a consent screen built based on Scope defined. If the user clicks no nothing happens but if the user clicks yes and allows to give access you will be redirected back on client-side something called callback or redirect URL specified in the previous step with authorization code. Now the Client has Authorization Code only thing the Client can do with it is go back to the Authorization server once again and ask for an Access Token. If the Authorization Code is the valid Client will get back Access Token but now client will also get back ID Token as well because we are implementing OpenID Connect flow. Now client have users information in ID Token it can just simply decode it for users’ information. That’s why if you see the above image you will see Hello Nate! on callback URL because of information in the ID Token. Now as I said if information in the Token is insufficient you can hit userinfo endpoint. Basically you can go to the accounts.google.com (Resource Server) and ask for more user information in exchange for Access Token we have.
That’s how OpenID Connect flow helps us to solve the problem of Authentication.
I hope this blog helped you to understand What is OpenID Connect and What Problem it Solves. Thank you