In the architecture diagram that we initially discussed at the starting of this section, we successfully
set up the key clock also inside our locker.
So now there can be two types of applications who want to interact with my key clock observer in order
to get an access token or I.D. token so that they can start interacting with that resource.
So first, let's try to construct the example of posthuman.
So posthuman application will help us to invoke any risk apps that are deployed on resource over.
But since Resource Somewhere is a secured, a place where all my resources are deployed, like account
details, card details, launce details.
So my bowsman can directly invoke.
First, it has to get the access token from the key.
Glock's over the same access token.
It can go and hand over to the resource.
So in order to get the response from that, it's also.
So here, though, I say it is a posthuman app, but it can be any scenario where one epper trying to
interact with other aipa, like if you construct inside the microservice network, one microservice
may be trying to interact with the other microservice.
So there there will be no user involved.
It just that two systems are trying to connect with each other so that the information between them
can be shared securely after properly authenticating and authorizing that application that is trying
to get that data from a secure resource server.
So if you recall our previous or two framework discussions in the scenarios where there is no user in
Waad, we have to adopt claimed the credentials or Duflo.
As you can see, this is the claim, the credentials grant tape that we have inside water.
So here there is no user involved, a client application.
It can be an microservice application trying to interact with the resource.
So what to get the data from it.
But since resource server is a secured application force, it will try to interact with the observer,
saying that these are my client I.D. and Clancey.
Correct.
So there is no user involved.
Please give me an access token.
Once my observer, which is here, Keith server right at claim to credentials, it will hand over a
token product client.
And once the access token is given to the client, my client will try to invoke resource server directly
with the access token to get the response from it.
If the access token is really a valid access token, my resource server will give you a proper response
to my client.
So how much resource server will know whether a given access token is a valid or not?
Is it will try to go and check with the authorization software internally to understand the value of
that given access token.
So now we have a clear understanding what is client credentials granted.
So in order to invoke my resource server stapes to get account details, card details, launce details.
First, I need a client credentials which will help me to get an access token using that access token.
I can invoke my securest AP is deployed on this also to get a proper response.
So in order to create a client, you have to make sure that you are in the right riyal.
So here you can see we are on the right trail, which is easy bandeau.
So click on the client by default.
There are certain clients created by the key Cluck's server for internal operations.
But since I want to create a brand new client credentials, I need to click create.
So here client I.D., I can use as easy bank API since this client is used only for API to API invocation.
I'm giving the client name as easy bank API.
So the client protocol obviously has to be open and reconnect, which is built on top of WATO framework.
So I am clicking sale.
So once my client is created, you can see the client name is displayed on the top.
If you want, you can again go to clients and look for the easy bank API.
So here.
The client is created.
But in order to know the secret of my client, our credentials are for my client.
First, I have to provide details about my client.
So as you know, there are many grant type flows inside.
What framework?
The very standard grantee flow is authorization code flow.
But here, since there is no user involved, we can disable the standard flow, which is authorization
code flow.
If you go around the question mark, it will clearly show this is the authorization code floor.
But since there is no user involved, I'm just turning it off.
Similarly, implicit flaw also involve the user.
So let it be simple and direct access grant also involves user, because this is the resource one up
credentials directly hand over to the client.
But here, since there is no resource Wawona, there is no user.
We can disable this also select access type as confidential, because our client will maintain claim
daily and claim secret.
It is not like open to public only who has access to client secret, then only they can use blind application
detail and invoke the key Block Sarwari APIs to get the access token.
So once they change to confidential, you can see I got one more option, which is service accounts
enable.
So here service accounts enable supports, client credentials grant, which means there are two service
accounts, like one API is trying to interact with the other API.
But this is the perfect flow that we want to follow.
So let's make it on.
Once we make those changes, scroll down and click sale.
As soon as you click save, there will be a credentials tab that comes on the top.
So if you see, this is the secret that your client should use whenever they're trying to interact with
the key clock server for an access token to my client, Bayley's Easy Bank API.
And the secret is this one.
So if you want to regenerate, you can click, which will give you a new secret ID.
So this way, we successfully set up a client that can be used in the client credentials, Grant Titlo.
So let's try to set up the resource server in the next lecture so that we can make it all this together.
Work to get the access token.
And pass that to resource our and resource our can validate with that orzo and provided a proper response
to that boatsman application.
Thank you.
And I'll see you in the next lecture by.