In the previous lecture, we discussed about what the different components involved in any or to floor
and at the same time we also discussed there are five different grant types.
Are outflows involved inside what framework?
And based upon the scenario that we want to follow inside our application, we can choose one of these
Kranti based upon security requirements.
When I say ground floor or what floor, that means these are the floor, that authorization.
So our client and resource servers, they follow in order to generate tokens, valid tokens and interact
with each other.
So in this lecture, let's try to see the first Grunty, which is authorization code.
You can see this is the high level floor that will happen inside the authorization code, grant type
or two floor.
This is very similar to what we have done on the Stack overflow website.
Comparing to that scenario, I can see I'm a user and the resource former client is the stack overflow
website observer and the server is the Google.
So first, as a user, I will go to the client website and I will say I want to sign up or login into
your application and you can leverage my resources which are staying in the Google resource.
So like last name my email to let me into your application.
So then client our stack overflow website, they will say, OK, you tell the server of the Google that
you are okay to share the credentials and I'll redirect them to the login page.
You have to enter your Gmail credentials and prove your identity.
So that's what will happen in step three, where I'll be related to the observer of the Google and I
have to enter my credentials.
Once I enter my credentials, the Observer will give you an authorization code to the client.
Please remember, authorization code is not the access token.
We are not Tejinder.
The access token now in the next step, which is to file claim, will make a request again, this time
in the back, and by taking the authorization code to the Google, also saying that it seems the user
brought his identity.
And this is the authorization code that I have received from you.
I want to generate the access token for that user based upon the authorization code that you have shared.
So then again, Observer will validate the attribution code that it previously shared.
And if everything is valid, it will give you a token in step six to the client.
Once client has the token in its hand, it will directly call the resource over in the back end.
Like I want to access the resources of so-and-so user.
And this is the access token that I received from the ATO.
Now resource server will internally validate with what is this token is really valid that you shared
to the client.
If both resources were an observer agrees like this is a valid token and it does not expire in the last
step, that is also will give the protected resources to the client, which in this case my last name,
first name email to that stack go through.
So with this the flow will complete and I'll be able to log into the stack overflow website or any client
application you can see in the back and particularly in step two and three, where client is making
a request to the Observer.
Initially, it has to send the following important details in order to generate a authorization code.
The first one is Client Eighty.
If we can recall client ID is the idea which generated for each and every application whenever someone
registered themselves in the Google or GitHub or Facebook.
I can go to Google website and I can say I want to leverage your Gmail login inside my website and I
can register by providing whatever details that they are asking me.
Poster.
They will give me a client along with the client credentials like client secret.
So in the step two and three, I'll just pass a client to prove OK, I belong to Stack Overflow.
I want to make a request to your Google ads over.
And next is the redirect you want to redirect your is a value which the ad server will redirect once
the login of the user is successful.
If we have mentioned some value during the registration of the client initially, then Ottawa will make
sure to direct to the default value.
If you don't mention this redirect, you arrive at each and every request.
Next scope is similar to authorities like we are requesting the Odzala.
I want to get access to a gun with a scope like read or write, based upon the scope that we are sharing,
the observer will decide whether I want to generate a token for this client or not.
Next step is a value which is used to avoid of attacks by generating a token at the client.
So you can expect the same value coming from also.
And it's also that we make sure that no one interpreter requests and no one tampered the request.
And at last, we also should send response time with the value call, which indicates that the observer
that inside or do we want to follow the authorization code granted now that services response drive
with the value code to understand or get this client application?
They want the authorization code and they were following the authorization code.
Correct.
So once we send all these details in step two and three and get the authorization code in step four,
as you can see again in step five, you were client after receiving the authorization quote from Ottawa,
they will again make a request to the Observer for a token belong to that particular user.
So this time they have to send code.
Code is the value that we received in the above steps like operation code value.
Next in this client, 80 unclaimed secret along with the client, I should also send the client secret,
which is like my password to the Observer to prove, OK, I'm the original stack overflow for whom initially
Google issued a clean, tidy and clean cigarette.
If this client I clean secret are wrong, obviously Google come to know this request is not coming from
the stack overflow and they will deny the request.
And the last two are LeGrande type and redirect to redirect you what you already know that we are discussing
the top and grant with the value attribution call like we have to indicate to our observer, which granted
that we want to follow and we are mentioning Operation Code, which identifies that we are following
alteration for granted inside our flow.
So once these values are sent in the file by the client, that token will be issued by the Observer.
You might have observed that in order to get the access to open, the client made a request to observe
what two times one is initially with only client and redirecting the user to that Google login page.
And in that step we get the alteration code from the Observer.
Next, by taking this Operation Call client again made a request to the Observer with both attrition
code and client credentials.
And this time I will get the access token from the ATO.
You may ask like, why do we need two different step?
Why can't we to both of them in a single step, like in a single step, I can send my client credentials.
I can then redirect.
You are everything scop CSR token and I can redirect the user to login page of Gmail and I can get the
access token in a single step.
Yes, I will also agree that we can achieve this in a single step.
But the reason why we follow two different steps in operation code grant type is it will provide you
more security in the very first step.
First iteration server will validate whether the user, the resource owner who is providing credentials
on it login page is also a valid user resource.
Whether or not if he's a valid resource Worner it will generate the automation core to the client.
And in the next step, client has to prove its own identity by providing client credentials and attrition
call in order to get the access token.
So this way we have two level of security in this flow and we also have implicit grant type where these
two steps are clamped into a single step and we don't have that attrition code in between directly within
a single step, we get the access token from the observer, but these days no alteration.
So we're like big organizations.
They are encouraging us to use the implicit grant type, which has only one step further.
They want everyone to follow the authorization code grant type due to the security issues.
That's why if we have it, strong reason why you have to go implicit grant, then only go otherwise.
Please use the authorization code grant type only with this.
I'm assuming you understand what is a code grant type inside all.
To flow, how the navigation, our request and response will flow during authentication and authorization
flow.
Thank you.
And I'll see you in the next lecture where we discuss about the implicit guarantee.