Do you wonder how participants or stakeholders interact in the OAuth standard? They do it by using grant types. There are four grant types: • Client Credentials • Resource Owner • Authorization Code • And Implicit. Each grant type has its own flow to acquire an access token, and these flows involve the interaction of public or confidential clients. We’ll learn more about the grant types in just a minute, but first, we’ll find out more about clients and how they communicate. The OAuth standard defines two types of clients: Confidential and Public. An example of a confidential client is a web application running in a web server. This type of application is able to protect the client key and client secret. On the other hand, public clients aren’t able to keep client secrets. Examples include Mobile apps with a password embedded inside, or JavaScript apps running in the user’s browser. These clients can’t ensure the integrity of the client secret. The client secret is prone to be hijacked or reverse engineered. Confidential and public clients communicate with the authorization server in two distinct ways: via the front channel and via the back channel. The front channel involves interaction between the user and the authorization endpoint through the user-agent. Because it’s based on HTTP redirects, all the request and response information must be passed in the redirected URI by using the GET method. On the other hand, the back channel involves direct communication between the client and token endpoint. Because it’s not limited to HTTP redirects, the token request includes parameters and other information as part of the body of a POST request. Now let’s take a look at the details of grant types in OAuth. The client credentials grant type provides a client application a way to access its own service account. The client credentials are required when the client requests an access token, which allows the access to the protected resources under its control. This grant type is used when an application needs to access or make service calls to backend services required to perform its work. It’s only used by confidential clients. Let’s see how this grant type would be used in a possible scenario. Here, the client requests an access token from the token endpoint through a client authentication with the authorization server. Once the authorization server authenticates the client, it issues an access token, which is sent to the client application. The next grant type is the Resource Owner Password Credentials, also known as the username-password authentication flow. It’s used when the user, or resource owner, has a trust relationship with the client. The client must be capable of obtaining the user’s credentials. For example, through an interactive form on the front channel. This flow is also used to preserve backward compatibility with old OAuth integrations. Let’s see how this grant type would be used in a possible scenario. Here the resource owner provides his username and password to the client application. Then the client application uses the user credentials to request an access token from the authorization server. The authorization server authenticates the client and receives the user credentials. If the credentials are valid, it issues an access token to the client application. It can optionally issue a refresh token as well. The next grant type is Authorization Code. Like the previous grant type; it also issues a Refresh Token. Since the Authorization Code is a redirection-based flow, it’s suitable for clients that are able to interact with user-agents, like web browsers, to receive incoming requests from the authorization server. It’s optimized for confidential clients. Web applications such as JavaScript apps or third party clients, without a trusted business relationship with the API provider, are common examples that use this grant type. Let's see how this works. In this scenario, the resource owner uses an application to perform an action, which requires authorization, such as posting or logging in. Then the client application, through the user-agent, redirects the user to the authorization endpoint. This URI is used by the authorization server to redirect the user-agent after granting, or denying, the access. Once the authorization server authenticates the resource owner, it redirects the user-agent back to the client, by using the provided redirect URI. The authorization code is included as part of the redirect URI. Before using the authorization code to request an access token, the client authenticates with the authorization server including the redirection URI used to retrieve the authorization code. Finally, the authorization server authenticates the client, validates the authorization code, and verifies that the included redirection URI is the same URI that was used when requesting the authorization code. If everything is ok, the authorization server issues an access token, and optionally a refresh token. The Implicit grant type is similar to the Authorization Code grant type. The main difference between these two is that in the implicit grant type, an access token is expected instead of a code. Then the user-agent redirects the client to the web-hosted client resource, which returns a web page, typically with a script that accesses the full redirection URI to extract the access token. After the access token is extracted, the user-agent passes it to the client. This flow improves the responsiveness and efficiency of some clients, since it reduces the number of round trips required to obtain an access token. However, it requires extra attention to avoid the access token exposure on the client side. Because it doesn’t include a client secret and authorization code, this flow is mainly used by public clients. With all of these grant types, how do you know which one to implement? Grant types are chosen based on the access token owner and the client type, and whether they can keep secrets or not. The best usage for Client Credentials grant type is on B2B transactions and batch processes without a Resource Owner. The Resource Owner Credentials grant type is preferable when you trust the Client App, who’s in charge of handling the resource owner credentials. The Authorization Code grant type best usage is when the client app delegates the resource owner credentials to the Authorization Server, and consent is needed. The best usage of the Implicit grant type is when the client app is a user-agent-based, Mobile or a Single Page Application. To learn more about OAuth, checkout the other videos in the series. Thank you for watching!
