Like we are discussing in the previous lecture, we can use the authorization code to grant ploa exactly
like we discussed for the public facing client like single page applications, Web applications, native
applications, because they can distort the claim to secret anywhere.
The reason is anyone can decompile and check the source code of these applications easily with the help
of browser and other tools that we have available.
So far, these public facing claims, we have a a different flavor of operation called flow.
It will work exactly like Operation Court Flow.
But instead of using blank to secret, we use a mechanism pixy, which means Brufsky for court exchange.
So there are very minor difference between pixy attraction called flow and normal alteration called
grand flow that we discussed previously.
So Bekesi enhanced atrisco called Flow will use the following step.
The very first one is when user clicks login client app creates a cryptographically random code verifier
like it will generate a random value by leveraging some encryption algorithm.
We call that random value as code, verify it.
And from these random value, it will again generate a different value card for the challenge.
So during the first interaction with the alteration software, my client application will only share
the code challenge, but it will not share the randomly generated code verified because using quarter
verified, only you can validate a court challenge is valid or not.
So my code verifier is indirectly acting as a client secret.
Instead of having a dedicated client secret, that will remain always same in this approach, my client
application will generate every time a random code verify.
So once my code challenge is passed to the operation software and my user will enter his credentials.
And if his credentials are correct and proper, my operation southwestward the court challenge that
shared by my client application and redirect the user along with the authorization code.
Once my client app receives the authorization code, this time when it's trying to get an access token
from the key clock.
So what are any orzo?
Along with the authorization code, it will also pass the code, verify that it intially generated in
the step one.
Now, my key clock server will try to check the validity of my code challenge by using the core to verify
which is the key for all these cryptographic operations.
So with the help of my core to verify if my geek like server is able to matches the code challenge provider,
then Michy Glock's, our our observer will return with an access token.
So this way, indirectly, without the need of dedicated claim to secret claim to Web applications,
they can maintain the authorization code ground floor using the Bixi method approach.
The reason why we have to incorporate core verified and court challenge is suppose a hacker trying to
intercept that request after we received the authorization call.
So if we try to send authorization code to the key squad to get an access token, he need the word generator
quarter verified, which is being stored under local stories are browser cookie and the client Web application.
And that really my hacker don't know what is that random value.
So due to that reason, the operation code will be useless for him.
Only the application, which originally invokes the geek locks, were able to get an authorization code.
It can only try to get an access token by passing code, verify any other persons who are trying to
intercept in between.
They can't get any value from the clerk server because they don't have what Ginal called verify for
the court challenge that was initially shared to that key clock server.
So this is the representation of that to Code Florida Pixy method.
So as you know, first user will let public client that I want to access my resource server.
So my client application will try to pass the court challenge and my Ozair will throw a login page to
the user after user enter his credentials.
And if it is a valid, my observer will return the authorization code.
So now in the.
A step when I'm trying to get an access token, my client application, along with the operation call
it should also pass the court to verify that it intially generated at the step three.
So if my court verified and court challenge they both are matching with each other, then only my operation
server will give you access token to the user.
So this way we can implement authorization code grant flow without the need of maintaining clanged secret
inside.
Are you why web applications?
Thank you.
And I'll see you in that next lecture by.