What is OAuth 2.0 —OAuth authorization flow in a simple way
Have you ever clicked social login (Facebook, Google, etc.) when you want to sign in to a website? I think that’s not a question I should ask, you may have done it hundreds of times. Some of you may know what’s behind the scene and if you are a newbie in the field of web and API security you may not. OAuth2.0 has a lot of use cases rather than just social logins. This article may not just be for newbies, I will explain some common misunderstandings and evolution of the OAuth2 framework. I will call it a framework not just as a protocol since the core spec leaves quite a lot of room for various implementations to do things differently depending on their use cases.
First of all, you want to know the difference between authorization and authentication. In simple terms, authentication is the process of verifying who someone is, whereas authorization is the process of verifying what specific data, files, and applications a user has access to. OAuth2 is an authorization framework, it is not for authentication. Nevertheless, with the combination of OpenID Connect, it is used for authentication as well. I will talk about it in another article.
History of authorization — The delegated authorization problem
You may already have a question about where is OAuth 1.0? Let’s get into some history and why did such a framework emerge. Back in 2007, the web was not complex as it is today. They used login forms to handle identity. We must provide our data explicitly such as name, email to every website we want to login.
For example what if another website wants to send an email on behalf of me. Can you think of a way to do that securely? In the past, a common pattern was to provide my original login credential to 3rd party website. This mechanism has a very dangerous security flaw. The website only wants to send an email but we are giving whole access to my data including read-write permissions. If there is any security breach on that site or we cannot trust it, all my data is in danger. Also, no proper way to revoke the access unless you change the password. This is one such use case. Nowadays, it is more than sending an email on behalf of you. It may be read your contacts, access your photo album, know your verified email, read your Facebook friend list. In all these scenarios we only need to delegate part of the user data to 3rd party applications.
OAuth came to the rescue in 2007. You can learn more about the history at oauth.net/about/introduction. In 2012, an improved version of OAuth was released as OAuth 2.0. It is the most widely used authorization framework today.
OAuth 2 Flow
Now we know a bit of background and why do we need it. Let’s say Spotify wants to access my contact list in Google. Here is some terminology used in OAth2.
- Resource owner (User)
- Client
- Authorization server
- Resource server
- Access token
- Scope
- Consent
Let’s understand the above scenario depicted in the picture. You visit spotify.com and it asks for contacts from Google to see your friends who use Spotify. When you click the Connect with Google button you are redirected to Google's login which is trusted to provide your credentials. In the redirecting URL, you can see callback URL, Respond type, and Scopes (in this scenario it is contacts) usually passed as query params. Then google verifies your credentials and asks for consent to allow spotify.com to access your contacts. Afterward, the browser is redirected back with the callback URL and authorization code. Then spotify.com/callback receives the authorization code and sends it to their backend. Spotify backend exchanges that code with an access token. This is some string usually kept in Spotify backend that is scoped only to contacts. Using that access token spotify.com is able to get your contacts. This is what happens in OAuth 2.0. In the above picture dashed arrows depict API calls or communications that happen at the backend.
You may wonder why we cannot get the access token directly without an authorization code. It is for better security. Frontends are less secure than backends. In case your browser has a malware type extension it is able to obtain your access token and access your resources without noticing you. Authorization code is a short-lived one-time code. Once you are redirected with the code backend immediately fetch the access token. However, in case the 3rd party application doesn’t have a backend it can mention Respond type as token instead code. This is called Implicit grant. But this is not recommended for developers.
The access token can be revoked at any time by the resource owner. Also if the 3rd party app wants different scopes rather than initially granted, it should follow the same flow again.
For mobile apps instead of code, there’s an extension called Proof Key for Code Exchange (PKCE) to the Authorization Code flow to prevent CSRF and authorization code injection attacks.
That’s it with OAuth 2.0. I think you understand the concept behind it. But there’s more. OAuth 2.1 is coming. One key difference is it is going to drop the Implicit grant. You can learn more by visiting oauth.net/2.1. Also, OAuth 2.0 is used for authentication as well. This is a bit controversial as OAuth is an authorization framework. Implementing OpenID Connect top of the OAuth 2.0, we can use it for authentication. Let’s meet with another article with OpenID Connect.