1 00:00:00,210 --> 00:00:07,770 We have been discussing a lot about operations over and over, saying that operation several issues, 2 00:00:07,770 --> 00:00:12,240 the access to guns and refresh tokens to the client and client. 3 00:00:12,240 --> 00:00:18,090 Every time they want to access a particular resource, they will share the access token issued by the 4 00:00:18,090 --> 00:00:19,900 operations over to the resource. 5 00:00:19,900 --> 00:00:21,420 So what level? 6 00:00:21,430 --> 00:00:28,140 We also understand, like every time resource server receives access token from the client, it has 7 00:00:28,140 --> 00:00:35,460 to validate that with the operations of because these are two different servers are two different applications 8 00:00:35,730 --> 00:00:37,800 handling different responsibilities? 9 00:00:38,130 --> 00:00:38,850 Definitely. 10 00:00:39,180 --> 00:00:46,650 Resource Server is not aware of the access tokens issued by the operations that were to all the clients. 11 00:00:46,920 --> 00:00:53,240 So there should be this for the resource server to validate that access token with the operation. 12 00:00:53,250 --> 00:01:00,720 So for the same, we have three different ways that most of the other nations follow, and you can also 13 00:01:00,720 --> 00:01:03,540 follow any one of them based upon your requirements. 14 00:01:03,810 --> 00:01:11,730 The very first and basic way of violating the access token by a resource server with the authentication 15 00:01:11,730 --> 00:01:18,770 services by making a yapper call in the backend, like whenever a resource over this is the access token 16 00:01:18,780 --> 00:01:23,430 from the client, it can simply call and rest up a call to the Australian. 17 00:01:23,440 --> 00:01:30,950 So by sending a resume, this access token from this client daily, do you approve it or not? 18 00:01:31,170 --> 00:01:39,060 When Ottawa says, OK, this is the correct access problem which is issued by me only and exploration 19 00:01:39,060 --> 00:01:47,010 time also is not met, then in such scenarios it is so server will go ahead and issues the protected 20 00:01:47,010 --> 00:01:48,990 resources that client is requesting. 21 00:01:49,200 --> 00:01:51,540 So this is the basic first of it. 22 00:01:51,870 --> 00:01:59,730 And the second way is by having a common database, like whenever an Australian server issuing an access 23 00:01:59,730 --> 00:02:07,040 token, it can write into a database and the same database can be pointed by the resource server also. 24 00:02:07,350 --> 00:02:14,310 So in such scenarios, we saw server don't have to rely on the network to interact with the observer. 25 00:02:14,430 --> 00:02:21,720 It can directly check in the database whether the access can result from the client is really issued 26 00:02:21,720 --> 00:02:27,060 by the observer or not and what time it is sure whether it is expired or not. 27 00:02:27,060 --> 00:02:34,590 All sorts of details can be validated by using a common database between observer and resource server 28 00:02:34,590 --> 00:02:35,820 as shown in this figure. 29 00:02:36,270 --> 00:02:43,590 Finally, the last approach is that this also can validate the signature of the token. 30 00:02:43,590 --> 00:02:51,540 If we can recall from our JWT tokens, the signature of the tokens can be validated by having some secret 31 00:02:51,540 --> 00:02:56,460 keys maintained by the both parties to make sure that no one is tampered. 32 00:02:56,580 --> 00:03:05,220 So following the same approach outside of work can generate a token access token by using some encryption 33 00:03:05,610 --> 00:03:07,580 algorithm with the secret. 34 00:03:07,860 --> 00:03:13,560 So whenever someone sends the same access token to the resource server in this scenario is also what 35 00:03:13,720 --> 00:03:15,090 don't have to make a call to. 36 00:03:15,090 --> 00:03:22,500 The alterations are it doesn't have to look into the database or it can simply check the signature or 37 00:03:22,500 --> 00:03:28,740 hash value of the token generated with the security that it maintains to understand if the token is 38 00:03:28,740 --> 00:03:29,590 valid or not. 39 00:03:29,610 --> 00:03:33,540 As you can see, every approach has its own pros and cons. 40 00:03:33,750 --> 00:03:39,150 If you see the last approach, which is violating the token signature in this scenario, you will never 41 00:03:39,150 --> 00:03:43,410 depend on the network to Calderazzo our database. 42 00:03:43,710 --> 00:03:52,320 But if we have a clear and real time checking with the observer, you can always rely on the first approach, 43 00:03:52,320 --> 00:03:54,780 which is through that recipe calls. 44 00:03:54,990 --> 00:04:02,700 But if you don't want to overburden your observer network in such scenarios, you can maintain a common 45 00:04:02,700 --> 00:04:05,760 database which can be leveraged by both observer. 46 00:04:05,760 --> 00:04:06,180 And it's. 47 00:04:06,900 --> 00:04:13,020 So with this now, we also have a clear understanding what are different ways that Isaza was valid access 48 00:04:13,020 --> 00:04:14,450 token with the alteration. 49 00:04:14,460 --> 00:04:20,550 So now we have a clear understanding on all the parameters that we have inside. 50 00:04:20,550 --> 00:04:21,630 What framework? 51 00:04:21,870 --> 00:04:27,170 Let's try to wrap up this section by discussing the summary of it in the next video. 52 00:04:27,390 --> 00:04:27,960 Thank you. 53 00:04:27,960 --> 00:04:30,420 And see you in the next lecture by.