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!
