Imagine that you are a developer, you have a new application or a website, that will be used by other people. They will have to somehow go to your site or your application to do it. Besides, future users already have a whole bunch of accounts, passwords, and logins. It makes no sense to come up with another one for you. It will be much more convenient if users are able to access your application through the account they already have, like Google, Twitter, Facebook, or other services. All these services use the Open Authorization protocol OAuth to provide user information to third-party applications.

In this topic, we are going to take a closer look at this protocol. We will find out how it works, describe the roles it defines, and look at its implementation schemes that exist in the current version of the OAuth 2.0 protocol.

OAuth roles

In OAuth 2.0, the following four parties are involved:

• The resource owner (the user) gives access to some portion of their account. In general, this may be any resource that has access restrictions. More specifically, this may be data like photos, documents, contacts, or services like posting a blog entry or transferring funds.
• The resource server (the API) contains the user's information being accessed by the third-party application. It is to accept and validate access tokens and grant the access request in case the user allows it.
• The authorization server (can be the same server as the API) issues a token to the client to access the protected resource after successful authorization by the resource owner.
• The client (the application) is attempting to act on the user's behalf or access the user's resources. To do so, the client needs to obtain permission. There are two ways to do it; either by directing the user to the authorization server or by asserting permission directly.

Among the four parties involved, the client is of two different types and we will talk about them in the next section.

Client types

There are two types of clients: public and confidential. The former cannot maintain the secrecy of the client's secret while the latter can.

An example of a confidential client could be a web app, where no one but the administrator can get access to the server, and see the client's password.

As for the public client, it is usually a mobile phone application or a desktop application that has the client password embedded inside it. Such an application could get cracked, and this could reveal the password. The same is true for a JavaScript application running in the user's browser.

Okay, now we know about roles. The next step is to talk about OAuth implementation schemes.

Implementation schemes

There are four types of implementation schemes:

• Application flow means that the application uses its client's secret to obtain an access token. The user does not have to provide authorization at any stage. This type requires the client's secret security.
• Implicit flow scheme means the application requests an access token from the gateway server. If the user grants permission, then an access token is provided. Then the user passes the access token to the application. This scheme type is only for public clients.
• Password flow means the user provides the app with a username and password to access the user's data. After that, the client directly contacts the provider's API to request an access token. In this case, the application must be trusted not to store the username and password.
• Access code flow means the user is authorized through a special form. In case of successful authorization, its code is provided to the client. The client sends the code to the provider's API and receives an access token in return.

The application flow is only for confidential clients and the implicit one is only for public clients. Password flow and access code flow can be implemented for both public and confidential clients. The only difference is that the client's secret will not be applied to the public client, but to the confidential client.

Let's start working with the OAuth algorithm.

Working with OAuth

Let's find out how OAuth is used. When you want to register, for instance, your application on a website, you, first of all, will need to receive permission for your app. This is done by using access_token which is the main entity of OAuth.

The access token works as the secret code that should be sent with an HTTP request to the API so that the service is sure that you have enough rights to get information from the API.

Before an application can receive an access_token, the user should confirm access to that application.

Let’s see how it works:

1. A developer of an application wants to use an API, so they must go to the site of the corresponding API and register the application there to get a client_id and a client_secret.
2. After they have registered the application and received the client_id and client_secret, they must create an authorization link which will contain, in query parameters; the client_id, redirect_uri (where the user will be sent after confirmation; redirect_uri itself must be allowed in the settings of the application), response_type (what should be returned in case of success), and scopes (what rights the user must provide to their account; in our case, we won’t use scopes).
3. The user follows this link and authorizes access (clicks the “allow” button), and is redirected back to the developer’s specified redirect_uri with the response here.
4. The developer uses this response to get access_token.

Conclusion

To sum up

• OAuth is the Open Authorization protocol that helps protect users' information.
• There are four OAuth roles; resource owner, resource server, authorization server, and client.
• There are two types of clients: confidential and public, depending on whether the application can maintain the secrecy of the client's secret or not.
• There are four types of implementation schemes: application flow, password flow, access code flow, implicit flow.

We encourage you to do some independent research to get more information about OAuth (opens new window)!