OAuth 2.0

The OAuth 2.0 protocol is a very popular way to authenticate a user, even though the protocol was initially designed to be used as a way to authorize third-party services to access the user's data. In a nutshell, the OAuth 2.0 protocol involves four parties:

Resource owner: A person who owns the data in the resource server. For instance, I'm the owner of my data on Twitter.
Resource server: The server that stores the data the client wants to access. For example, the Twitter API server is a resource server.
Authorization server: The server that will perform the authorization of the data access requested from the clients. Usually, the resource server and the authorization server are the same one.
Client: The application that wants to access your data.

In a case where we use OAuth 2.0 for authentication, for example, with GitHub, our application is the client and the user who tries to access our application is the resource owner. GitHub is the resource server and the authorization server. The following figure shows the authentication flow when logging in to our application with GitHub through OAuth 2.0:

Figure 10.2: OAuth 2.0 authentication flow

As you can see, the authentication process starts with the user clicking the Sign In with GitHub button on our application. Our application will redirect the user to the authorization page on GitHub, requesting permission to access the user's data on GitHub. If the user hasn't logged in on the GitHub side, GitHub will show a login form requiring the user to pass the authentication check on GitHub first. After that, the user will be able to grant data access to our application. The user will then be redirected back to our application with an authorization code that our application can use to get an access token from GitHub. Once the access token is retrieved, our application can use it to access the user's data on GitHub, such as the user's name, email address, and profile photo.

In the previous sequence diagram, many details are left out for the sake of brevity. For example, the user, as a resource owner, does not interact with our application or GitHub directly. It is through a user agent, most of the time a browser. And it is in the browser that the redirect happens.

In summary, authenticating a user is about verifying the user is really who claimed to be, either through a data source the application manages or through a third party.

Table of Contents for OAuth 2.0

Create new playlist

Sign In

Sign Up

Table of Contents for
OAuth 2.0