1
00:00:00,330 --> 00:00:07,250
Finally, we are into the last green tape that we have in order to flow, which is Refresh Tolkan Granter,

2
00:00:07,560 --> 00:00:09,150
let me clear you in what?

3
00:00:09,480 --> 00:00:12,620
Because we use this cranked up inside water framework.

4
00:00:12,870 --> 00:00:19,560
Think of a scenario where you used any of the grand that we discussed previously, like either implicit

5
00:00:19,560 --> 00:00:27,060
grant or alteration or granted, you got an access token from the Australian server and you send that

6
00:00:27,060 --> 00:00:33,480
to the resource server and got the required resources that you want from the resource server belongs

7
00:00:33,480 --> 00:00:33,780
to you.

8
00:00:34,050 --> 00:00:34,720
This was one.

9
00:00:34,980 --> 00:00:36,120
So everything is happy.

10
00:00:36,120 --> 00:00:37,750
Everyone is happy in this scenario.

11
00:00:38,070 --> 00:00:41,760
Now, suddenly your token expires because obviously.

12
00:00:41,760 --> 00:00:42,120
Right.

13
00:00:42,600 --> 00:00:45,990
US will not issue a token without any explanation.

14
00:00:46,500 --> 00:00:52,980
The reason is if you have a token without any explanation time, it is as good as credentials of the

15
00:00:52,980 --> 00:01:00,390
user and even how the token they can use it for any number of time, which is again a serious security

16
00:01:00,390 --> 00:01:00,710
issue.

17
00:01:00,720 --> 00:01:07,710
Due to that reason, every Utsav like they can define the timeframe based upon their organisation requirements.

18
00:01:07,980 --> 00:01:14,200
Usually it will be like one day or 60 minutes based upon the requirement from application to application.

19
00:01:14,340 --> 00:01:20,120
So due to that reason, there are good chances that your token may expect the access token we expect.

20
00:01:20,400 --> 00:01:25,100
So if access token expires, we should not, as the user are the resource.

21
00:01:25,110 --> 00:01:27,640
Once again, your access to organise expired.

22
00:01:27,750 --> 00:01:36,270
I want you to again address me as the Google observer to provide that and to provide a better user experience

23
00:01:36,270 --> 00:01:38,620
to the user, not asking credentials.

24
00:01:38,640 --> 00:01:45,570
Again and again, every 60 minutes or every one day, we have a concept called Refresh Tolkan also in

25
00:01:45,570 --> 00:01:46,000
what?

26
00:01:46,380 --> 00:01:51,840
So whenever we interact with The Observer initially during the operation code grant type, our implicit

27
00:01:51,840 --> 00:01:59,040
grant type, along with the access token, you also get the refresh token from the Utsav uses that refresh

28
00:01:59,400 --> 00:02:01,950
token and access token in the database.

29
00:02:02,220 --> 00:02:09,360
And whenever you get an error from the observer saying that you are access token is expired instead

30
00:02:09,360 --> 00:02:15,810
of you asking the resource Warner are user to enter the credentials again, what you will be doing is

31
00:02:16,020 --> 00:02:17,670
you will be sending the refresh.

32
00:02:17,680 --> 00:02:25,440
Spoken to the automation server with the GRANDPAP as refresh, indicating that my original access token

33
00:02:25,440 --> 00:02:29,470
which you share is expired and now I want to get the new access token.

34
00:02:29,700 --> 00:02:35,840
So in such scenarios, Alteration Server will validate the refresh token that it originally issued.

35
00:02:36,120 --> 00:02:43,980
If the refresh token is valid and if it belongs to the same user it initially issued, now the alteration

36
00:02:43,980 --> 00:02:50,440
server will issue again a new access token with the new expiration time along with the new refresh token.

37
00:02:50,610 --> 00:02:54,120
Please do remember we also get a new refresh token.

38
00:02:54,120 --> 00:02:56,970
We can't use the same refresh token again and again.

39
00:02:57,270 --> 00:03:00,730
That's the purpose of the refresh token as a name indicates.

40
00:03:00,900 --> 00:03:04,380
So in such scenarios, we use the refresh token granted.

41
00:03:04,650 --> 00:03:11,640
Like you can see here, there is no user involved or resource one removal because my client don't want

42
00:03:11,640 --> 00:03:16,740
to ask the user for his credentials in the Gmail application.

43
00:03:17,070 --> 00:03:23,680
Instead, it can rely on the refresh token, which is orginally issued from the Google Utsav.

44
00:03:24,120 --> 00:03:30,600
So in the initial scenario where we are using stack overflow, think of a scenario today I want to stack

45
00:03:30,600 --> 00:03:33,900
overflow and signed up using my Gmail credentials.

46
00:03:34,230 --> 00:03:37,380
Now Stack Overflow has a refresh token and access token.

47
00:03:37,650 --> 00:03:40,980
Maybe after three or four days again went to the stack overflow.

48
00:03:41,340 --> 00:03:47,030
But now this time Stack Overflow will not ask me to enter my credentials again.

49
00:03:47,310 --> 00:03:53,790
Instead, what it will do is for my access token is expired based upon the response from the resource.

50
00:03:53,800 --> 00:03:58,800
So as you can see in the very first step, the stack overflow directly.

51
00:03:58,800 --> 00:04:04,320
Make a call to the resource ever since because it is holding the access token which it received from

52
00:04:04,560 --> 00:04:05,090
day one.

53
00:04:05,370 --> 00:04:06,420
Now resource server.

54
00:04:06,420 --> 00:04:10,360
After validating with the observer, it says it is expert body.

55
00:04:10,410 --> 00:04:13,530
I'm sorry, I'm throwing it for 030 now.

56
00:04:13,800 --> 00:04:16,170
Client realizes the token is expired.

57
00:04:16,380 --> 00:04:21,480
It will make a separate request to the observer like in step three, along with the refresh token that

58
00:04:21,480 --> 00:04:22,590
it received initially.

59
00:04:22,830 --> 00:04:29,490
If the refresh token is valid, no observer will issue a new access token and refresh token based upon

60
00:04:29,490 --> 00:04:30,900
the new access token.

61
00:04:31,020 --> 00:04:35,130
It will call the resource server to get the protected resource.

62
00:04:35,370 --> 00:04:41,400
If the access token is valid, my resource server will provide the resources requested by the client

63
00:04:41,670 --> 00:04:48,180
and client also will sell the new new refreshed token in some database table for future because without

64
00:04:48,180 --> 00:04:51,900
reference token, it can't request again for a new access token.

65
00:04:51,900 --> 00:04:58,260
Instead, it should force the user a resource one to enter the current Chelse again in the autofill.

66
00:04:58,470 --> 00:04:59,490
So for such instant.

67
00:04:59,510 --> 00:05:05,810
He says, we use a refreshed stock and granted and refresh token Graniteville never happened during

68
00:05:05,810 --> 00:05:07,430
the initial log.

69
00:05:07,610 --> 00:05:13,850
I suppose if user advisers want to go into the stock, quote, from the very first time, I can never

70
00:05:13,850 --> 00:05:19,760
use the refresh stock and directly because in order to use a refreshed stock and grand type, I should

71
00:05:19,760 --> 00:05:25,580
have at least logged in and signed up successfully at least once before.

72
00:05:25,940 --> 00:05:32,120
Then only my client will hold a refreshed account and it will leverage to get the active stock.

73
00:05:32,120 --> 00:05:37,790
And whenever it expands, as we discussed in step three, one client is making a request to the observer

74
00:05:37,790 --> 00:05:38,750
endpoint.

75
00:05:38,750 --> 00:05:43,690
In order to get the new access token, it has to send the client data and client to correct.

76
00:05:44,060 --> 00:05:51,230
And next is a refreshed token, which it originally received from the initial authentication and authorization.

77
00:05:51,620 --> 00:05:57,560
And third one is the scope and fourth one is that important, one which is a grant type with the value

78
00:05:57,560 --> 00:05:58,090
refreshed.

79
00:05:58,730 --> 00:06:05,510
This indicates the observer that the client is sending a referral token and it want a new access token

80
00:06:05,510 --> 00:06:06,670
for the user.

81
00:06:06,920 --> 00:06:12,550
As we discussed, this flow will be used only in the scenarios where the access token is expired.

82
00:06:12,800 --> 00:06:18,650
Instead of asking the user again and again to log in, we can leverage the refresh token to get the

83
00:06:18,920 --> 00:06:20,260
new access token.

84
00:06:20,600 --> 00:06:28,940
We should never make our access tokens without any expiration time because it creates a lot of security

85
00:06:28,940 --> 00:06:30,700
issues regularly.

86
00:06:30,890 --> 00:06:39,500
You have to get the access tokens from the order was based upon the refresh tokens, even in the scenarios

87
00:06:39,710 --> 00:06:46,150
where we follow resourceful and or corrections grunty, where all the clanged operations have resource

88
00:06:46,160 --> 00:06:48,590
over everyone staying in the same organization.

89
00:06:48,830 --> 00:06:56,210
Even in that scenario, also for real indication and repatriation purpose, we should never store the

90
00:06:56,450 --> 00:06:58,420
resources on our credentials.

91
00:06:58,670 --> 00:07:05,430
Instead, we should leverage the refresh tokens in order to get the new access token every time.

92
00:07:05,660 --> 00:07:12,680
So with this, we are done with a long discussion of all the grant types involved inside what to flow

93
00:07:12,830 --> 00:07:14,090
in the next lecture.

94
00:07:14,390 --> 00:07:21,770
Let's try to understand how Resource Server will connect to automation server whenever it resumes access

95
00:07:21,770 --> 00:07:27,170
token to validate whether that the access token is a valid one or not.

96
00:07:27,350 --> 00:07:29,450
Thank you and see you in the next video by.