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.

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.

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.

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

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.

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.

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,

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!