The technology behind the smoothest sign-in process | OAuth2.0 and OIDC
We all have seen this at one point: when we try to sign in to some website, they present an option to sign in with Google. In this blog, let’s dive into the frameworks and technologies behind this smoothest sign-in process.
In a nutshell, this sign-in process is an implementation of OIDC and OAuth2.0 frameworks. But before we go into these frameworks, let’s understand the basics.
There are some entities involved in these processes, so it’s better to introduce them at this time.
Meet our app developer, and call him Steve, who is developing a ToDo App. The App has a server — call it AppServer, and a UI — call it AppUI.
The App has users who sign up on the app, and create Todo lists. Let’s bring our user to the stage — Bob.
Authentication and Authorization
Authentication is verifying who you say you are.
Authorization is verifying whether you have the right to access what you are asking for.
Bob comes to AppServer and creates a Todo list called Shopping. The server needs to know that this is Bob (that’s called Authentication). Later Bob comes to AppServer and asks the server to add “TV” to the shopping list. The server first checks that this is Bob, and then checks whether Bob has permission to add “TV” to the “Shopping” list (that’s called Authorization).
Most of the time, the server is only interested in Authentication and doesn’t really care about Authorization. If the server knows that this is Bob, then it doesn’t need to check whether Bob has permission to add to the shopping list — after all, it’s Bob’s list, and who is the Server to tell Bob that he can’t add TV to his shopping list?
How do you implement authentication?
Let’s create a basic version of Authentication: email and password.
Bob opens up the ToDo App in the browser, App asks him to sign up. Bob provides his email and password. UI sends the email and password to the server. The server creates a new row with email and password in the User database. Next time, Bob comes and signs in to the application, provides his email and password, and the server verifies that the email and password match by querying the database. If it matches, then the server knows that this is really Bob!
Sounds easy peasy! but it’s actually not. It’s easy to implement this flow, but there are so many security problems with this approach. You can check out what kind of problems arise when the AppServer stores email and password in the database and does the whole authentication process itself.
Sign in with Google
So now sign-in with Google comes into the picture. Bob is signing in using Google into the ToDo App.
The AppServer doesn’t want to do the whole authentication process and things that come with it: maintaining a database, updating passwords, and other kinds of stuff. So the App delegates the authentication process to Google. Let’s see what it looks like from the perspective of Bob. Bob opens the ToDo App on the browser, and he sees an option to sign up via Google. He clicks on it. He is redirected to the Google webpage to sign in on Google. After signing in to Google, the browser sends him back to the ToDo App, and Bob is logged into the ToDo App as well. That sounds very smooth!
Bob doesn’t need to have a password for the ToDo App. He doesn’t need to remember the password for a particular website, he just needs to have a Google account and he can use his Google account to sign in to the ToDo App. It’s very convenient for the user.
Now let’s look at it from the perspective of the App. The user comes to the App’s UI. UI asks the user to sign in to Google. After the user signs into Google’s website, Google transfers back a token to the App UI and UI then sends that token to the server. The server verifies the token by inspecting the token — hey this token is coming from Google, and it belongs to the user. No need to check into the database, no need to talk to Google, just by inspecting the token the AppServer can tell that Bob is the user and he has signed in via Google. Isn’t it amazing? That’s the power of JWT — JSON Web Tokens. We will return to JWT in a while, but for now, let’s keep in mind that Google provides a token containing user information, specifically this token is called IdToken.
This is another framework of authentication, where different Apps don’t need to check the email and password of the user, and can rather rely on Google to do the authentication. The diagram below shows the high-level interaction between different entities.
Low-level flows of data between these entities:
There are two different frameworks involved in the above interaction. One is OAuth2.0, and the other is OIDC (OpenID connect). So let’s talk about them to understand how they fit here.
OAuth2.0
OAuth2.0 is a generic framework for authorization. Remember, authorization is the server verifying whether the caller has rights to access the resource the caller is asking for. Let’s take an example with the ToDo App. If you don’t know, there’s a feature in Google Calendar to add tasks. Turns out, Bob is fond of Google Calendar, and he sometimes adds tasks to the calendar. Bob then gets confused about where he added the task — in the ToDo App or in Google Calendar, and that frustrates him. So the ToDo App came up with a feature called task sync. Basically, Bob can sync his Google calendar tasks in the ToDo App.
How does the ToDo App sync tasks from Google? The AppServer must ask Google to get the tasks of Bob, and Google will tell the AppServer — Hey, sure I can fetch tasks for you but first can you please provide your email and password so I can verify you’re Bob. Does that mean the ToDo App should ask Bob for his email and password to his Google account, and provide it to Google to fetch Bob’s tasks? That looks weird. Firstly, that defeats the whole purpose of the passwordless sign-in process. Secondly, why would Bob share his email and password with the ToDo App? The App basically can do anything it wants with Bob’s Google account. That sounds scary! What do we do now? How can the ToDo App get Bob’s tasks from Google without having to provide email and password, and make sure that the ToDo App can only access tasks from Google and nothing else?
That’s where the OAuth2.0 framework shines. First, Google implements this framework and allows any Apps to access user’s tasks (and only tasks). The conversation between the App, the user, and Google looks like this:
App: Hey Bob, would you like to sync your tasks from Google into the ToDo App?
Bob: Yeah, that sounds awesome!
App: Great! I’m sending you to Google and I have asked Google to let me access your tasks.
[Bob goes to Google]
Google: Hey, Give me a second, let me verify who you are (authentication).
[A couple of seconds have passed by..]
Google: Hey Bob, looks like the ToDo App wants to access your tasks from the calendar. Are you okay with that?
Bob: Yes, I’m fine with that.
Google: Sure, I’ll allow the ToDo App to access your tasks, and don’t worry they won’t be able to access anything else but tasks. Now, I’ll send you back to the ToDo App’s webpage, and they will take care of the rest of the process.
[Google sends Bob back to ToDo’s webpage. ToDo App is busy doing some work. A few more seconds pass by…]
App: Bob! Now you can see all your tasks from Google Calendar in our App.
Behind the scenes, it looks something like this. Here App is the client, Bob is the resource owner, Tasks in Google Calendar is the resource, and within Google, there are two servers Authorization server and Resrouce server. In the above conversation, Bob was talking to the Authorization server from Google.
If you want to learn more about the OAuth2.0 framework, check out this. This is the original publication of OAuth2.0 and it’s straightforward to understand the framework from there.
But how’s sign-in with Google related to OAuth2.0?
OAuth framework came up with the flow between different entities — client (ToDo App), resource owner (Bob), Resources (Google tasks), authorization server(Google), and resource server (Google). However, their main use case was around authorizing the Client (ToDo App) to access resources (Google tasks) without the resource owner providing email and password to the Client, thus increasing the security and privacy of users.
This framework doesn’t really help with passwordless login. There’s no mention of authenticating a user on an application. But if we look at the sign-in with Google Flow, it involves the same entities and similar information exchange between these entities. And that is an implementation of the OIDC framework.
OIDC
OIDC is a layer built on top of the OAuth framework to help with authentication problems. It allows a third-party application (ToDo App) to verify the identity of the user (Bob) and to obtain basic profile information about the user. The authorization server (Google) provides an identity token (IdToken) of Bob to the third-party application (ToDo App), using which the application can verify the identity of Bob and get basic information about Bob (email, username, etc.). And yet the question arises: how can the ToDo App authenticate users by simply inspecting a token, ensuring not only its trustworthiness but also confidently affirming that this token is indeed from Google and belongs to user Bob? Remember the case with email and password where the App has to verify in the database whether the email and password match or not? But in this case, there are no checks against a database, neither does the App check with Google. It just happens in place! And that is the power of JWT!
Stay tuned to learn about JWT, in the next blog.
