Auth 2.0 and OpenID connect
This article discusses OAuth 2.0 and OpenID connect with explained examples and sample implementations. Most of the developers are talking about this subject without a deep knowledge or an understanding of the context.
You may find a lot of confusing information online. By reading them it is hard to grasp the process of how these protocols work! I am here to explain it as simple as possible.
Before we jump into OpenID and Auth 2.0. Let’s walk through the history of these protocols to get a better understanding of where these protocols came from and why they were built this way?
This is the most basic type of authentication we can do on the web.
This is called a simple login or form authentication. Above is just a simple example of when you have to verify an application with an email and a password or a username and a password.
After filling the information and user submitting the form, the back-end of the website checks whether the username and password exist in the database and if it does exist, compare the username and the password hashes to see if they match in the verification process.
Usually, passwords are saved to the database using hashing for security reasons, to make sure it’s not stored as just plain text. We store an application cookie in the web browser to keep track of the user and in the back-end, we keep a session id for the cookie.
This is basically how our authentication process started out.
Some small industries are still using this kind of implementations, but the majority of the industrial products and projects are no longer using these kinds of implementations due to the complex modern security issues and maintenance issues. Auth 2.0 and OpenID connect are kind of some industry`s best practices that they are trying to find easy solutions for the problems associated with these implementations. If we look at the kind of common identity (authentication and authorization).
If we look at use cases from 10 years ago, you can see it was a very simple login form where you could just fill the form and some cookies and log in using username and password.
But Here I am talking about delegated authorization.
This is essentially who has ever seen the screen that says “Hey I’m [app name] wants to access your Facebook account that will allow us to see your public profile and your birthday etc. “However, it won’t let the app to post on Facebook on behalf of you. If you have seen this screen, you would notice that it is the same as Google or Twitter or on any social platform.
That’s a common pattern on the Internet now. You probably have more than 15 weird apps that are connected to your Facebook account or to other social platforms. I realized that this pattern is everywhere so if you ever clicked yes on that prompt you’ve already used it with or without your knowledge.
Let’s talk about why this was invented.
A few years ago, there wasn’t a good way of solving this problem. They did not approach the problem in the right way.
This is a very famous screenshot from the early days. Yelp tried to solve this problem, but they did not approach the problem in the correct way. No offense to them but they didn’t come up with a better solution. Since they were a brand-new start-up, they tried to get as many as people possible to use their service. The solution they came up with was asking users for their Gmail address and the password to fill in. Then they use the user’s information to log in to the user’s Gmail account to get the user’s contacts and later log out from the account and promise to permanently delete the password and email address from the database or to never save them to the database.
To explain in simple words as possible, they’re basically saying “Hey we will log into your Gmail account for you and on behalf of you, will grab your Contacts will send them an email we will then log out from your account and will throw away your password we promise not to do anything with it”
So, in case if you’re wondering whether this is a good approach, this is not!
You should never let anyone know your email and password since it’s the key to your kingdom. Because they can access all your apps that are currently in use by using your email. Furthermore, you can access to reset passwords especially bank accounts and personal data access such as your google drive data and many more.
If you have agreed to give your password of the Gmail account to any third-party applications, I suggest you change your password. And hopefully, you have two-factor authentication setups for these accounts.
This is just a good example to illustrate what the problem was back then and how they didn’t have a better way of solving it at the time. We have a better approach now.
Auth 2.0 basically the protocol that was invented to solve this problem.
We’re going to talk about it at a high level and then we’re going to progressively go down and talk about its lower levels of how this works.
We start with a user like me or you who says like, okay I trust Gmail I may kind of trust the startup called Yelp. I’ll trust him enough to let him have access to adjust my Contacts, but I don’t want him to be able to delete my email or go look at my Google Photos on Google drive or anything similar.
So, here’s what we do today!!
We would have a button on the application on Yelp or anything that says connect with Google authorized with Google link. Auth flow is basically, the set of steps that ultimately result in the application being able to access that information we’re having the authorization.
This diagram illustrates how this works at a high level, so let the user click on that connect with Google button or link to Google.
What happens here is that the user’s browser redirects most likely to Google domain, accounts.google.com at Google domain they’re going to prompt a login page requesting you to enter email and password.
This is a little better though, because now at least I’m giving my password to Google to Yelp rather than to someone else. I would feel OK to login to Google as I can see that in the address bar it’s actually a Google domain that’s being presented.
Assuming I logged in successfully, then I will get prompted with a window that says “Hey this application Yelp is trying to access your list of things like, public profile, contact, etc. Are you sure you want to allow this? yes or no?”. The user explicitly has to give the consent whatever they are granting access to so that you don’t get tricked into agreeing to give information that you don’t know which is.
Users can always click on No in which case we’re done and nothing else interesting happens. But if the user clicks yes then the browser will re-record one more time back to the application; back to where it started to a special place on the application called a call-back or redirect you.
Let`s learn some special terms we use in auth 2.0 and OpenID.
OAuth 2.0 terminology
● Resource owner
● Client
● Authorization server
● Resource server
● Authorization grant
● Redirect URI
● Access token
Resource owner — Who owns the data that the application wants to get.
Ex: — I have some contacts in my Google account and I’m the resource owner of that data and I’m the person who can click the “yes I allow this application” to access this data.
Client — This is just a way to refer to the application.
Ex: — Yelp (just keep using Yelp, Yelp would be the client)
Authorization server — The system that I can use to say “yes I authorized this permission”
Ex: — accounts.google.com (I can log in to my google account and click yes then I accept)
Resource server — API or the system that holds the data that the client wants to get to.
Ex: — Google contact API
⮚ Sometimes the authorization server and resource server are the same things. Sometimes they’re together in the same system but many times they’re separate.
Authorization grant — The thing that proves user has clicked “yes I consent to this level of permission”
Redirect URI — When the authorization server redirects back to the client application (it’s just where should I end up at the end of this flow if the user clicks “yes” where do they need to go next)
Access token — The key that they use to get into whatever the data that I granted access to or granted permission to on the resource server. (access only read-only)
More OAuth 2.0 terminology
● Scope
● Consent
Scope — The way this works is, the authorization server has the list of scopes that it understands. It might be like contacts.read, contacts. write, email. read, email. delete any type of permission that makes sense in the system and then the client application when they kick off this flow they say “I just want the scope that gives me access just to read his contacts”. If they need to do more stuff, they could request multiple scopes.
Consent screen — Presented to the user that says “Yelp is asking for permission to do XYZ ABC and are you sure you want to allow this” and users give an explicit ability to consent or not consent to that particular level of access or that particular level of scopes. The client used by the authorization server to generate that screen.
Even more OAuth 2.0 terminology
● Backchannel (highly secure channel)
● Front channel (less secure channel)
Backchannel — If I have my server code running on my server which only, I have access to and I make an API request or some HTTP request from my server to another server (Ex: — Google API) and that’s going over HTTPS. It’s SSL encrypted no one can intercept that communication and its highly secure.
Front channel — it’s something like your browser. Your browser is secure but there are some loops or there are some places where stuff could leak from the browser.
Ex: — when we are building a website or web application and I want to keep a secret password or secret key in my web application, if I put it in the HTML or JavaScript on my web app technically somebody could just right click and view source and look through my source code and see it.
⮚ Coming back from the authorization server to the client also happening on a front channel
⮚ The front channel is used to interact with the user, so the browser is used to interact with the user.
Calling back
error=access_denied&
error_description=The user did not consent.
OAuth 2.0 flows
● Authorization code (front channel + backchannel)
● Implicit (front channel only)
● Resource owner password credentials (backchannel only)
● Client credentials (backchannel only)
Problems with OAuth 2.0 for authentication
● No standard way to get the user’s information
● Every implementation is a little different
● No common set of scope
Because of these problems Open ID Connect protocol was introduced. It’s not fair to call Open ID Connect a separate protocol. It’s a 5%,10% layer on top of OAuth 2.0 that says if you are using OAuth for these authentication use cases just do this other extra stuff.
⮚ OpenID Connect is for authentication
⮚ OAuth 2.0 is for authorization
OpenID Connect adds
● ID token — has some of the user’s information. It represents the ID or the information about the user
● User Info endpoint for getting more user information
● A standard set of scopes
● Standardized implementation
⮚ This is an OpenID Connect to request rather than an OAuth request. It is both an OpenID Connect request and OAuth request. We are just using OAuth to do OpenID Connect.
⮚ OpenID Scope means, when we go over to the authorization server all the normal stuff happens, we get asked to allow access to your public profile, we get back to the call-back with an authorization code and we extract code for an access token, but we also get back an ID token. We get back both. ID token can be like immediately consumed by the application to understand or decoded by the application to understand who the user is that just logged in. We closed the gap for doing authentication. Not just authorization and the access token that we get back as the client application can then be used if we need more information about the user, we can call the user info endpoint to get more info about the user using that access token.
⮚ The ID token because of the signature can be independently verified by the application without even necessarily having to go back to and talk to the authorization server.
Identity use cases (today)
● Simple login (OpenID Connect) — Authentication
● Single sign-on across sites (OpenID Connect) — Authentication
● Mobile app login (OpenID Connect) — Authentication
● Delegated authorization (OAuth 2.0) — Authorization
Use OAuth 2.0 for:
● Granting access to your API
● Getting access to user data in other systems
(Authorization)
Use OpenID Connect for:
● Logging the user in
● Making your accounts available in other systems
(Authentication)
Let`s look OAuth 2.0 authorization code flow with our new knowledge.
Here when the resource owner clicks the “connected with google” button, the client will be redirected to the authorization server URL to login to the user’s account. After the user logged in to the account. The authorization server will ask the client to give permission to the resources you want to give when the user click the yes button authorization server call the call-back URL with authorization code. In backchannel, the client calls the authorization server with authorization code and exchange that code for an access token. Using this access token client call the resource server and get the contact details. The resource server will not give access to any other information other than contacts.
Below you can see the implicit flow diagram. This flow used for client application which doesn’t contain a back-end server. Then there is no any backchannel.
This diagram explains how OpenID connect works.
