Now, in this lecture, let's try to understand the Fort Grant type inside the floor, which is claimed
declensions.
So before diving into the details, I want to give you a scenario where we will use client grant.
So think of a scenario where you don't have any U.A. application, where you don't have any resource.
One are user involved.
You have multiple backend applications, which they share data between them, like in the scenario of
myco services, where hundreds of applications trying to interact with each other and shared some secured
information between them.
So in such scenarios, you decided instead of maintaining the authentication and alteration flow inside
each and every application, you decided to keep that all the alteration, logic and authentication
logic in a separate server called Observer and every application before it tried to communicate with
the other application inside your organization, they have to prove their identity and get the access
token from the observer, which will be eventually shared to the other application to get the resources
from it.
So in such scenarios, we will use client credentials GRANDPAP as the name indicates.
And you can also see there is no involvement of resources or not are used in this outflow, as you can
expect.
This is the floor that will happen inside the client credentials granted in the very first step, client
will directly call the Observer when, as a client, it's one of the backend application.
Make a request to the Observer to get the access token, bypassing the client credentials like its own
client and client credentials, which it received initially when it existed with the Observer.
And since there are no user involvement here, there won't be any user credentials will be shared in
the second step, where observers validate the client credentials and given access token to access their
particular resources.
Now, in the third step, the client will make a request to other application where it trying to get
some protective resource, bypassing the broken IT result from the orzo.
And at last the resource server or other backend application will validate this token by connecting
to the observer and eventually provided the resources that client is requesting.
Based upon our discussion in the step one, where the client is making a request to Utsav to get their
act astrocom, it has to send the following three values in the request.
One is the client ID and sekret to prove its identity to the ottowa like I belongs to so-and-so organization
and these are my client credentials and client ID.
Next, a scope similar to authorities, the level of access that client is requesting like.
Right.
And the last one is a grant.
Here are the differences.
We will send a value as client underscore credentials to indicate observer that there is no user involved
and we want to use the client credentials grant type to generate the access token.
And you can easily expect this is the most simplistic grant type flaw in what?
Because we awarded one of the component, which is resource Worner are user inside this floor.
We use this application flow of client grant type only in the scenarios.
There is no user and you are involved and we're multiple backend application.
They are trying to share data between them by using the backend apps like Aristocats.
I hope it makes sense to you.
Let's try to discuss the last grant that we have in the next lecture.
Thank you.
And by.