1 00:00:00,180 --> 00:00:06,540 In this area, let's try to understand what the JWT and what at once features that it provides compared 2 00:00:06,540 --> 00:00:09,870 to normal tokens that we have discussed in the previous reviews. 3 00:00:09,880 --> 00:00:13,950 So firstly, JWT means Jason Webb token. 4 00:00:13,980 --> 00:00:15,640 That's a full expansion of it. 5 00:00:15,840 --> 00:00:23,600 It is a token implementation that leverages Jason format designed to use inside Web request. 6 00:00:23,610 --> 00:00:31,320 And it is the most common and favorite token type that many systems and users applications that they 7 00:00:31,320 --> 00:00:37,520 use these days due to its features and advantages like very lightweight. 8 00:00:37,650 --> 00:00:41,790 And it uses Jason format, which can be understood by everyone. 9 00:00:41,940 --> 00:00:47,610 And at the same time it allows us to send the data in an encrypted format. 10 00:00:47,910 --> 00:00:52,940 JWT tokens can be used beyond authentication and authorization. 11 00:00:53,070 --> 00:01:00,360 Like if I want to share certain information or if I want to store certain information inside my token 12 00:01:00,360 --> 00:01:06,720 itself, rather than storing inside the service memory, which will degrade the performance of the server 13 00:01:06,720 --> 00:01:08,010 over a period of time. 14 00:01:08,190 --> 00:01:12,840 What I can do is I can store all such information that I want to communicate to. 15 00:01:12,840 --> 00:01:19,200 The other system are for my future reference inside my token, excel in an encrypted format. 16 00:01:19,350 --> 00:01:25,230 So basically JWT token has three parts which are separated by dots. 17 00:01:25,560 --> 00:01:33,450 You can see below is the sample JWT token that code generator and the very first, a local related part 18 00:01:33,450 --> 00:01:39,830 is it had their part and right now this is all base64 encoded value bozkurt. 19 00:01:39,870 --> 00:01:47,790 After the first dot we have a payload, our body part of the token where we store all the user related 20 00:01:47,790 --> 00:01:52,800 information or any other information that we want to store for ourselves. 21 00:01:52,830 --> 00:02:00,570 And lastly, we have a signature part and this is an optional only if we are going for the encryption 22 00:02:00,720 --> 00:02:07,950 and if we want to make sure that no one tampered you had that and body parts of your token, then only 23 00:02:07,950 --> 00:02:10,620 you will use this last part, which is a signature. 24 00:02:10,620 --> 00:02:16,710 But otherwise, header and bodies are mandatory sections, whereas signature is an optional one. 25 00:02:16,870 --> 00:02:23,760 So if you go and look the header part, so usually we use header pad to store the metadata, our info 26 00:02:23,760 --> 00:02:30,270 related to the token, like what type of algorithm I have use to generate the signature of my token 27 00:02:30,480 --> 00:02:37,280 or what is a type of token, is it a JWT or any other token type, etc.. 28 00:02:37,290 --> 00:02:41,540 So initially when we generate a token, this is how the data looks. 29 00:02:41,580 --> 00:02:49,470 Was that before sharing to the client that will be converted into base64 encoded so that people on the 30 00:02:49,470 --> 00:02:52,650 other side they can easily decode using base64? 31 00:02:52,710 --> 00:03:00,360 Both the header part we have it by the part where we can store is related to user the rules, which 32 00:03:00,360 --> 00:03:05,700 can be later be used by authentication and authorization purposes. 33 00:03:05,700 --> 00:03:12,540 And there is no limitation what we send inside the body and what is the size of it. 34 00:03:12,720 --> 00:03:19,560 We can send any size of the data inside body part, but it's our responsibility to keep it as light 35 00:03:19,610 --> 00:03:28,470 as possible so that we don't create latency issues in the network here you can see inside the body and 36 00:03:28,470 --> 00:03:35,130 storing sub name and eighty eight means issue time issue out. 37 00:03:35,130 --> 00:03:38,700 What is the time that I have issued that Goken post? 38 00:03:38,700 --> 00:03:41,940 The body will be converted again into the encoded format. 39 00:03:41,940 --> 00:03:48,120 So you can see here what is a need for me to store the data inside the body of the token. 40 00:03:48,300 --> 00:03:49,230 There are two reasons. 41 00:03:49,230 --> 00:03:55,710 One is you want to share the information on the other side of the parties so that they can also use 42 00:03:55,710 --> 00:04:01,440 these rules and authorities that you are sending for their business logic and the other purposes. 43 00:04:01,440 --> 00:04:07,350 If you go with the traditional ways of generating a Shushan, you have to maintain all such details 44 00:04:07,500 --> 00:04:14,280 inside your database, like what is the Shishani when I have created what is the exploration aim of 45 00:04:14,280 --> 00:04:14,430 it. 46 00:04:14,550 --> 00:04:20,100 So all such details, you have to store it in some memory location are some database. 47 00:04:20,190 --> 00:04:27,120 And every time for every request, you have to retrieve those details and compare what you have received 48 00:04:27,120 --> 00:04:30,000 from the client to avoid such scenarios. 49 00:04:30,300 --> 00:04:36,450 We can maintain such information like I have created this token at this point of time and this is the 50 00:04:36,450 --> 00:04:37,980 expiration time of it. 51 00:04:38,130 --> 00:04:45,150 So all such information I can maintain inside the token itself so that we don't have to maintain such 52 00:04:45,150 --> 00:04:49,590 information inside association, subversion, our memory, our database. 53 00:04:49,590 --> 00:04:53,010 So now we have an understanding of what is header, what is body. 54 00:04:53,280 --> 00:04:59,840 Let's try to understand the most important part of the JWT token, which is a signature value. 55 00:05:00,000 --> 00:05:06,810 I was think of a scenario where I am generating a token and I'm sending the token to other internal 56 00:05:06,810 --> 00:05:09,630 application inside my company firewall. 57 00:05:09,660 --> 00:05:16,740 So in this scenario, I'm pretty sure no hackers can access my token and they can't tamper that valuable 58 00:05:16,740 --> 00:05:18,420 tool for such scenarios. 59 00:05:18,640 --> 00:05:25,800 I can simply send the header and body of the token since I'm believing the other side of the application 60 00:05:26,010 --> 00:05:32,870 and we can communicate any such information between my application and the other side application. 61 00:05:33,330 --> 00:05:41,520 But if we have a scenario where the token will fly into the open world through the web, then we have 62 00:05:41,520 --> 00:05:48,210 to make sure there are enough measures to detect that someone tampered that token because you are not 63 00:05:48,210 --> 00:05:55,840 storing that token anywhere inside or backend application like in the server memory database. 64 00:05:56,010 --> 00:06:01,830 Then how do you validate if someone sends whether this is the reality that you generate or not so far 65 00:06:01,830 --> 00:06:04,290 that we use the digital signature. 66 00:06:04,530 --> 00:06:12,720 So what we do is we generate a hash value outside header and body value that got generated in the token. 67 00:06:13,050 --> 00:06:16,390 We send that hash value inside that token also. 68 00:06:16,410 --> 00:06:24,030 And if someone tampers my head and body values from the other side of the party and send the value again 69 00:06:24,030 --> 00:06:31,050 to me, what my backend application will do is it will try to isolate the hash value of the header and 70 00:06:31,050 --> 00:06:38,940 body again and compares that already value present in the token with the newly generated hash value. 71 00:06:39,090 --> 00:06:46,540 And if the both matches when it's a match, just not the content but the hash value of the both values 72 00:06:46,560 --> 00:06:53,850 matches, then it believes, OK, this is my original token, that a generator and no one tampered the 73 00:06:54,030 --> 00:06:54,500 token. 74 00:06:54,660 --> 00:06:59,960 So that is the purpose of the digital signature inside our JWT token. 75 00:07:00,180 --> 00:07:07,770 And the way that we can create this JWT token is you can see here we can choose the encryption algorithm 76 00:07:07,770 --> 00:07:16,950 that we want to use as the base64 encoded had better value darte base64 encoded the value of the payload 77 00:07:17,070 --> 00:07:20,610 along with the secret code that you maintain in the server side. 78 00:07:20,790 --> 00:07:28,170 So this secret key will play a very prominent role in generating the hash value outside from your Heidrun 79 00:07:28,380 --> 00:07:29,880 Bellard values. 80 00:07:29,910 --> 00:07:33,480 So on a high level, this is how the token looks. 81 00:07:33,720 --> 00:07:39,510 The very first part is header and next is already our payload and the last one is the signature. 82 00:07:39,540 --> 00:07:46,740 So all these parts are separated by the dots present in between and JWT tokens are heavily used in the 83 00:07:46,740 --> 00:07:53,460 history, email and environment, and they have a great advantage compared to small tokens which are 84 00:07:53,460 --> 00:07:55,230 XML based standards. 85 00:07:55,240 --> 00:08:01,010 And since Jason Tokens uses this Furman, they're very light in nature. 86 00:08:01,140 --> 00:08:06,800 You may ask why do you want to send the base64 encoded value that had better body? 87 00:08:06,960 --> 00:08:14,640 You can also encrypt and send that Heidrun payload to provide more security on top of hash value that 88 00:08:14,640 --> 00:08:16,870 we maintain in the signature value. 89 00:08:17,140 --> 00:08:24,720 Yeah, even that scenario also is very valid if you have a stronger requirement of encrypting even the 90 00:08:24,720 --> 00:08:33,330 header and body so that no and authenticated application NCUA actual value is present inside header 91 00:08:33,330 --> 00:08:36,350 and payload, you are free to use them. 92 00:08:36,360 --> 00:08:44,250 But please remember, whenever you introduce encryption and decryption unnecessarily, it will use a 93 00:08:44,250 --> 00:08:51,960 lot of your server computations values so that by default you can always send your header and body in 94 00:08:51,960 --> 00:09:00,030 base64 encoded value, since that is very easy to decode and you can protect those values by generating 95 00:09:00,030 --> 00:09:03,300 a signature and hold it in the signature part. 96 00:09:03,420 --> 00:09:10,560 So in this way you can maintain the credibility of your token and make sure no one is putting your token 97 00:09:10,560 --> 00:09:11,760 in the next.