Yesterday I had to explain to a friend (a junior developer) what OAuth (OAuth 2.0) is. As I saw, It is relatively hard for a developer with little experience to grasp the idea behind it.
Most of the time, people don’t get the concept behind OAuth 2.0 and OpenID Connect just because they are poorly explained. So in this article, I will try to explain them in the simplest way possible.
What is OAuth 2.0?
OAuth is an authorization protocol. Please don’t mistake it with an authentication protocol. The sole purpose of OAuth 2.0 is to grant access to resources, not to authenticate users.
By granting access, we mean a hypothetical situation like this –a user wants to give some web application his Gmail contact list or the possibility the application to post on his Facebook wall.
Before OAuth, we did this by giving our username and password to the web application, believing that there will not be any unregulated actions using our credentials. Of course, you can see that this is pure insanity.
With OAuth 2.0, we don’t send our username and password to anyone.
How OAuth 2.0 works?
OAuth 2.0 follows a simple flow. But before we get familiar with it, we should list its participants.
Participants
Resource owner – The is the user. It could be anyone (you, me, John) who wants to grant access to some of his resources to other web applications (not necessarily web application).
Client – The client is the web application that wants our resource.
Resource server – This is the server responsible for keeping the user’s (resource owner) data.
Authorization server – The authorization server is often part of the resource server ecosystem. With resource servers, they belong to a common organization. But the sole purpose of the authorization server is to grant or decline access to some of the owner resources.
Authorization grant – The authorization grant is a code generated by the authorization server when a resource owner gives his consent.
Redirect URI – The redirect URI is often an URL located on the client. After the resource owner gives consent, the authorization server generates an authorization grant code and sends it to the client using the redirect URI.
Access token – Access token is a token generated by the authorization server when requested by the client with a valid authorization grant code. Later with that access token client can access specific resources on the resource server.
I know it sounds crazy complicated but let discuss the OAuth 2.0 flow. I promise you everything will get clear.
Flow
To provide a more clear example, let us have the following situation. As a user, you came across a very cool new social media web site – BeerAndDevelopers.drink. Fascinated by its functionalities, you want to share it with your colleagues and friends on Facebook.
Step 1 – You (the resource owner) click the “Share with friends on Facebook” button on the BeerAndDevelopers.drink website (the client).
Step 2 – The client redirects to the authorization server (authorization.facebook.com) and requests an authorization grant.
Step 3 – The authorization server using the resource server (wall.facebook.com) asks you If you consent. If you do, the flow continues.
Step 4 – After you have given permission, the authorization server generates an authorization grant code and redirects the client’s redirect URI.
Step 5 – Now the client has an authorization code. The next step is to request the authorization server for an access token in exchange for the authorization code. If the authorization code is valid, the authorization server sends the client an access token.
Step 6 – Using the access token, the client accesses the resource server.
Simple! Isn’t it?
Some of you may ask why we need to get the authorization code first and request an access token later? Can’t we directly ask for an access token?
Good question. We can, but we don’t do this because of security reasons. The first roundtrips (steps 2 and 3) are pure browser redirects. This way of communication is not secure enough.
That’s why when we get the authorization grant code, we validate it against the current user session, and only after that, we request an access token from the authorization server.
- Some flows use only back channel communication or front channel communication, but we do not discuss them here.
Consent
To simplify the example, I intentionally didn’t mention details about what user consent is. In step 3 in OAuth 2.0 flow (Request consent), things are not all or nothing. We, as users, can permit specific resources or actions. Things like “read contacts”, “post to wall”, “delete contact” etc. The generated access token can only access resources it has been permitted to. This is called scope.
What is OpenID Connect?
As I mentioned earlier, OAuth 2.0 is an authorization protocol, not authentication. Back in the days, many developers tried to use it for both – authorization and authentication. They used to upgrade the access token to hold some user profile data, which was very wrong.
By its nature, OAuth 2.0 does not support a way of handling user data, so any creativity from the developers was welcome.
Because of this, there were no standards, and each implementation was different.
OpenID Connect is just an upgrade to the OAuth 2.0. It is a very thin layer over OAuth 2.0. Its only responsibility is to handle user profile data.
OpenID Connect introduces some additional endpoints for requesting user profile data and one more token – id token.
Using OpenID Connect, you can request an access token and id token in the same flow.
