Finally, we are into the last green tape that we have in order to flow, which is Refresh Tolkan Granter,
let me clear you in what?
Because we use this cranked up inside water framework.
Think of a scenario where you used any of the grand that we discussed previously, like either implicit
grant or alteration or granted, you got an access token from the Australian server and you send that
to the resource server and got the required resources that you want from the resource server belongs
to you.
This was one.
So everything is happy.
Everyone is happy in this scenario.
Now, suddenly your token expires because obviously.
Right.
US will not issue a token without any explanation.
The reason is if you have a token without any explanation time, it is as good as credentials of the
user and even how the token they can use it for any number of time, which is again a serious security
issue.
Due to that reason, every Utsav like they can define the timeframe based upon their organisation requirements.
Usually it will be like one day or 60 minutes based upon the requirement from application to application.
So due to that reason, there are good chances that your token may expect the access token we expect.
So if access token expires, we should not, as the user are the resource.
Once again, your access to organise expired.
I want you to again address me as the Google observer to provide that and to provide a better user experience
to the user, not asking credentials.
Again and again, every 60 minutes or every one day, we have a concept called Refresh Tolkan also in
what?
So whenever we interact with The Observer initially during the operation code grant type, our implicit
grant type, along with the access token, you also get the refresh token from the Utsav uses that refresh
token and access token in the database.
And whenever you get an error from the observer saying that you are access token is expired instead
of you asking the resource Warner are user to enter the credentials again, what you will be doing is
you will be sending the refresh.
Spoken to the automation server with the GRANDPAP as refresh, indicating that my original access token
which you share is expired and now I want to get the new access token.
So in such scenarios, Alteration Server will validate the refresh token that it originally issued.
If the refresh token is valid and if it belongs to the same user it initially issued, now the alteration
server will issue again a new access token with the new expiration time along with the new refresh token.
Please do remember we also get a new refresh token.
We can't use the same refresh token again and again.
That's the purpose of the refresh token as a name indicates.
So in such scenarios, we use the refresh token granted.
Like you can see here, there is no user involved or resource one removal because my client don't want
to ask the user for his credentials in the Gmail application.
Instead, it can rely on the refresh token, which is orginally issued from the Google Utsav.
So in the initial scenario where we are using stack overflow, think of a scenario today I want to stack
overflow and signed up using my Gmail credentials.
Now Stack Overflow has a refresh token and access token.
Maybe after three or four days again went to the stack overflow.
But now this time Stack Overflow will not ask me to enter my credentials again.
Instead, what it will do is for my access token is expired based upon the response from the resource.
So as you can see in the very first step, the stack overflow directly.
Make a call to the resource ever since because it is holding the access token which it received from
day one.
Now resource server.
After validating with the observer, it says it is expert body.
I'm sorry, I'm throwing it for 030 now.
Client realizes the token is expired.
It will make a separate request to the observer like in step three, along with the refresh token that
it received initially.
If the refresh token is valid, no observer will issue a new access token and refresh token based upon
the new access token.
It will call the resource server to get the protected resource.
If the access token is valid, my resource server will provide the resources requested by the client
and client also will sell the new new refreshed token in some database table for future because without
reference token, it can't request again for a new access token.
Instead, it should force the user a resource one to enter the current Chelse again in the autofill.
So for such instant.
He says, we use a refreshed stock and granted and refresh token Graniteville never happened during
the initial log.
I suppose if user advisers want to go into the stock, quote, from the very first time, I can never
use the refresh stock and directly because in order to use a refreshed stock and grand type, I should
have at least logged in and signed up successfully at least once before.
Then only my client will hold a refreshed account and it will leverage to get the active stock.
And whenever it expands, as we discussed in step three, one client is making a request to the observer
endpoint.
In order to get the new access token, it has to send the client data and client to correct.
And next is a refreshed token, which it originally received from the initial authentication and authorization.
And third one is the scope and fourth one is that important, one which is a grant type with the value
refreshed.
This indicates the observer that the client is sending a referral token and it want a new access token
for the user.
As we discussed, this flow will be used only in the scenarios where the access token is expired.
Instead of asking the user again and again to log in, we can leverage the refresh token to get the
new access token.
We should never make our access tokens without any expiration time because it creates a lot of security
issues regularly.
You have to get the access tokens from the order was based upon the refresh tokens, even in the scenarios
where we follow resourceful and or corrections grunty, where all the clanged operations have resource
over everyone staying in the same organization.
Even in that scenario, also for real indication and repatriation purpose, we should never store the
resources on our credentials.
Instead, we should leverage the refresh tokens in order to get the new access token every time.
So with this, we are done with a long discussion of all the grant types involved inside what to flow
in the next lecture.
Let's try to understand how Resource Server will connect to automation server whenever it resumes access
token to validate whether that the access token is a valid one or not.
Thank you and see you in the next video by.