WEBVTT 00:03.850 --> 00:05.410 Hey, did everyone they share? 00:05.410 --> 00:07.210 And welcome to another video. 00:07.240 --> 00:10.890 This is also an important part of whatever you'll be building up later on. 00:10.900 --> 00:17.300 This is going to stand as an important part of that entire structure, this video that tokens. 00:17.320 --> 00:20.110 Now, a lot of people get afraid by the term of token. 00:20.120 --> 00:21.960 They think that token can be break. 00:21.970 --> 00:23.620 It's not secure and all of that. 00:23.950 --> 00:25.030 This is not like it. 00:25.060 --> 00:28.240 Tokens are arguably very, very secure. 00:28.270 --> 00:33.450 All the awards, the Google sign in, the Facebook sign in, almost all of them provides you the token. 00:33.460 --> 00:36.550 They are also using tokens as their internal infrastructure. 00:36.550 --> 00:39.250 So it is comparatively very secure. 00:39.280 --> 00:41.590 You cannot make anything else 100% secure. 00:41.590 --> 00:47.290 But all of the standard companies, every website that you see, majority of them are using token now 00:47.290 --> 00:49.750 how they are using the token further down the road. 00:49.750 --> 00:53.620 That is important structure and there's a lot of argument and debate we can have. 00:53.650 --> 00:54.130 Don't worry. 00:54.130 --> 00:58.960 I'll I'll tell you all the possible scenarios that can happen and we'll have a debate on this later 00:58.960 --> 00:59.650 on as well. 01:00.310 --> 01:06.550 So treat your token always as your car key and consider your car is being parked somewhere in the remote. 01:06.550 --> 01:11.430 So anybody who has this car key can actually claim the authority that this is my car. 01:11.440 --> 01:13.120 He is not the proper owner. 01:13.120 --> 01:14.830 He doesn't have the documents and everything. 01:14.830 --> 01:18.160 Yes, I do agree on that part, but he's having the keys right now. 01:18.160 --> 01:20.530 He can open your car, he can actually drive it. 01:20.530 --> 01:23.530 So treat your token very, very carefully. 01:23.560 --> 01:28.450 Now, as a user, they don't have much of the option to treat them as securely as possible. 01:28.450 --> 01:32.890 But as a developer, it's your responsibility to treat them as secure as possible. 01:32.890 --> 01:37.240 So make sure that you treat them as as as carefully as possible. 01:37.270 --> 01:39.940 Now, also, make sure that you expire the token. 01:39.940 --> 01:45.010 This is really a great functionality that is there and based on an ideal time of what your application 01:45.010 --> 01:46.780 is, is it an educational website? 01:46.780 --> 01:51.790 Is it a social media, whatever that is, the token should always and always expire and when the user 01:51.790 --> 01:55.750 logs in again, he should get a new token or a new token one here. 01:55.750 --> 02:01.090 So expiring the token, it can be two days, seven days, 24 days, whatever you like, but it should 02:01.090 --> 02:07.660 expire somehow so that it's if mistakenly or by some attacker, he gets the token that is somehow being 02:07.660 --> 02:10.510 just kind of a dumbed down after this amount of time. 02:10.510 --> 02:13.180 The important question is how this token is made. 02:13.190 --> 02:19.300 Now, this token is actually a three part of the sum, the first one being header, the second one being 02:19.300 --> 02:21.420 payload, and the third one being signature. 02:21.430 --> 02:23.890 Now, don't you worry, I'll explain to you what all of these are. 02:23.890 --> 02:30.010 But the important part is in the payload now token is generated based on some information that that 02:30.010 --> 02:31.630 token is carrying around. 02:31.630 --> 02:34.270 So that information literally is inside the token. 02:34.270 --> 02:39.460 When you are going to decode that token, you will be able to extract that information and know we never, 02:39.460 --> 02:43.240 ever pass the password inside the these kinds of payload. 02:43.240 --> 02:49.210 We usually go for only email or probably at a max, something like a request ID, so that from based 02:49.210 --> 02:51.730 on that ID, we can retrieve all the information of the user. 02:51.730 --> 02:53.170 So that's usually the flow. 02:53.170 --> 02:55.630 But what are these signatures and headers now? 02:55.630 --> 03:00.130 I can definitely show you more of the things in the presentation itself, but the website has done so 03:00.130 --> 03:05.170 much of a good job that I will actually say that click here, swipe up whatever you say and we're going 03:05.170 --> 03:06.910 to go on to the JWT website. 03:06.910 --> 03:11.200 So yes, JWT are the tokens also known as JSON Web Token. 03:11.290 --> 03:13.540 So first we're going to start with introduction. 03:13.840 --> 03:15.430 So what is the JSON Web token? 03:15.430 --> 03:20.200 It actually is a standard way, self contained way to securely transmitting information between the 03:20.200 --> 03:20.680 parties. 03:20.680 --> 03:26.440 So in this case, we are just saying we are using some signature to pass on a trust in this case that 03:26.440 --> 03:28.780 yes, you are the user who we are claiming to be. 03:28.900 --> 03:34.210 So somebody says when you should use the JSON web token, you should use it for authorization and information 03:34.210 --> 03:34.660 exchange. 03:34.660 --> 03:39.010 So both of them we are doing information exchange means we are allowing user to create something on 03:39.010 --> 03:43.270 our database and authorization that we are only allow him to log in and all of that. 03:43.270 --> 03:47.140 So these kinds of things are being used and they are mentioning up here openly. 03:47.230 --> 03:49.030 So what is the structure of this token? 03:49.060 --> 03:53.200 It is actually the header payload and the signature and that's why it always looks like this. 03:53.200 --> 03:57.820 So what comes into the header, maybe what type of algorithm we are using and there is no shortage of 03:57.820 --> 03:58.870 choosing between the algorithm. 03:58.870 --> 04:01.060 You can make it even more complex for that. 04:01.210 --> 04:04.780 And then the payload, whatever you want to send, that's the payload. 04:05.020 --> 04:07.420 It can be really something like this. 04:07.420 --> 04:08.530 The name admin. 04:08.530 --> 04:12.370 True, and more information that you can extract directly from here signature. 04:12.370 --> 04:14.080 Again, there is no shortage of signature. 04:14.080 --> 04:18.850 By default it uses an SHA 256, but you can go ahead and change that. 04:18.850 --> 04:21.070 So this is the mixture for 256. 04:21.070 --> 04:26.260 Really, really one of the security algorithms so far open source, kind of open source and it is not 04:26.260 --> 04:27.250 being broken yet. 04:27.250 --> 04:29.230 So that's why we are using it now. 04:29.230 --> 04:30.040 This is how it looks. 04:30.040 --> 04:34.180 And by the way, you can go on to the home page and can see how your code and token is going to look 04:34.180 --> 04:34.660 like. 04:34.660 --> 04:36.700 So this is how the token actually looks like. 04:36.700 --> 04:38.050 I know this is a really big string. 04:38.050 --> 04:38.950 That's how it looks. 04:38.950 --> 04:41.290 So the header something looks like this. 04:41.500 --> 04:45.130 The great thing is the library that we are going to use, we don't have to pass on all of these. 04:45.130 --> 04:49.930 We just pass on that what kind of payload we need to carry on and of course the expiration information. 04:50.050 --> 04:51.520 But that is also even optional. 04:51.520 --> 04:52.870 So we can go ahead and do that. 04:52.870 --> 04:55.990 Importantly, note down this simple warning here. 04:56.020 --> 04:58.360 JWT is our credential. 04:58.390 --> 04:59.470 Remember this always. 04:59.470 --> 05:00.400 I'll repeat myself. 05:00.430 --> 05:01.510 JWT is our. 05:01.610 --> 05:02.180 Credentials. 05:02.270 --> 05:06.620 Treat them as password, treat them as keys, which can grant access to the resources. 05:06.620 --> 05:08.250 So treat them almost like password. 05:08.270 --> 05:10.250 It shouldn't be handled lightly. 05:11.360 --> 05:12.670 So how are we going to use that? 05:12.680 --> 05:13.820 That is the big question. 05:13.820 --> 05:16.250 And that's what we are going to do exactly in this video. 05:16.250 --> 05:17.630 So I go ahead and search for that. 05:17.630 --> 05:21.050 Hey, I'm looking for a JSON web. 05:22.640 --> 05:23.540 Is it going to give me? 05:23.540 --> 05:26.270 No Jason Webb token. 05:26.540 --> 05:28.060 I hope now it gives me something. 05:28.070 --> 05:28.640 There we go. 05:28.640 --> 05:31.020 So we can see that we have Jason Webb token. 05:31.040 --> 05:32.930 There are a couple of other implementations as well. 05:32.930 --> 05:33.950 We don't want to go with that. 05:33.950 --> 05:36.530 We'll go just with the basic, which is JSON Web token. 05:36.770 --> 05:38.060 So look for it. 05:38.060 --> 05:38.780 There we go. 05:39.440 --> 05:42.020 And I hope you can see the weekly downloads here as well. 05:42.050 --> 05:43.100 Pretty insane again. 05:43.100 --> 05:45.230 So we'll be using the Jason Webb Tech token. 05:45.230 --> 05:46.370 The usage is pretty simple. 05:46.370 --> 05:52.970 You just use the JWT sign to sign the token and then we simply pass on the payload secret or private 05:52.970 --> 05:53.210 key. 05:53.210 --> 05:56.120 And then there are a few options and callbacks that possible. 05:56.120 --> 05:58.160 In case you want to use it, you can use it. 05:58.190 --> 06:02.990 You can also go ahead and define your algorithms, most importantly in the options you can pass on the 06:02.990 --> 06:03.530 expires. 06:03.530 --> 06:05.960 And some people prefer to change the algorithm. 06:05.960 --> 06:10.850 I don't I totally trust the has to 56, so I'm going to go ahead for that. 06:10.850 --> 06:14.270 So you can pass on the two days, 10 hours, seven days. 06:14.270 --> 06:16.010 This is the format, what you can pass on. 06:16.040 --> 06:19.670 You can even give the 62nd or something, which I wouldn't be doing that. 06:19.670 --> 06:22.160 That would be unnecessary and wastage of the time. 06:22.340 --> 06:29.600 Now looking up back a little bit onto the scrolling up here, notice we are able to sign. 06:29.600 --> 06:35.150 But what I wanted to show you a little bit further down the road in the documentation here is you can 06:35.150 --> 06:38.000 actually use JWT to verify again the same point. 06:38.000 --> 06:39.440 We just don't want to encrypt something. 06:39.440 --> 06:43.430 We also want to verify after the encryption so we don't have to decode it. 06:43.580 --> 06:49.610 We can actually go ahead and use verify and some of you might be asking that why don't we use the same 06:49.610 --> 06:51.620 JWT to encrypt our password as well? 06:51.620 --> 06:52.970 No, that's not how it works. 06:52.970 --> 06:54.590 That is actually a bad advice. 06:54.590 --> 06:57.170 So please don't do that and don't even have that question. 06:57.170 --> 06:59.570 So we can actually go ahead and decode. 06:59.570 --> 07:04.190 Once you actually decode this, then obviously I'll show you what the code actually gives you as the 07:04.190 --> 07:04.760 information. 07:04.760 --> 07:08.660 Basically, your payload is being extracted when you decode the information. 07:09.200 --> 07:12.380 So rest we can actually talk about as we move further down the road. 07:12.440 --> 07:14.030 So let's go ahead and copy this. 07:14.270 --> 07:19.520 And now you understand fully that why we are doing what we are doing, let's go ahead and have the JSON 07:19.520 --> 07:22.130 web token, pretty simple and small library. 07:22.130 --> 07:24.260 So let's go ahead and run the dev mode again. 07:24.620 --> 07:25.030 Okay. 07:25.160 --> 07:28.130 First thing as you all know that how we're going to go work with that. 07:28.130 --> 07:31.610 So let's go ahead and just below the script or whatever you like. 07:31.820 --> 07:35.180 Let's go ahead and call this one as JWT as the documentation says. 07:35.180 --> 07:36.800 But again, this is not compulsory. 07:36.800 --> 07:38.600 Feel free to call it even Superman. 07:38.810 --> 07:40.730 So let's go ahead and say require. 07:42.360 --> 07:43.470 The not request. 07:43.470 --> 07:44.040 Come on. 07:45.900 --> 07:46.830 Require. 07:46.860 --> 07:47.570 There we go. 07:47.580 --> 07:49.830 And we're going to say JSON Web token here. 07:49.830 --> 07:53.640 It is important to write this in Web token because it is a library that is being installed. 07:54.720 --> 07:59.550 Once this is being done, how we're going to create the token that is really the simplest and the easiest 07:59.550 --> 07:59.880 way. 07:59.880 --> 08:05.130 So once our user is being done, remember we have first created the user. 08:05.310 --> 08:11.640 It's not like we are saving that information onto this entirety of the thing into the database itself. 08:11.640 --> 08:13.110 We haven't done that yet. 08:13.380 --> 08:17.700 So I'm going to go ahead and say, hey, user dot token. 08:17.700 --> 08:20.010 So I'm using the model to generate that. 08:20.010 --> 08:24.360 And the first, let's go ahead and create a token before even saving that we haven't created yet. 08:24.360 --> 08:26.250 So I'm going to write a comment for myself. 08:26.250 --> 08:29.130 Token creation part goes up here, scroll it a little bit. 08:29.400 --> 08:29.940 Okay. 08:29.940 --> 08:33.030 So first let's go ahead and hold this token into available. 08:33.030 --> 08:38.730 That's important as the documentation says, we can just use the JWT dot and I can go ahead and sign 08:38.730 --> 08:41.190 the token and I can later on verify that as well. 08:41.430 --> 08:45.720 And I told you, you can just go ahead and create a token like this, but there is no point of creating 08:45.720 --> 08:47.130 the token like that. 08:47.130 --> 08:50.340 So the first thing that we're going to define here is the payload. 08:50.340 --> 08:55.230 And I can go back into the documentation to show you some of the stuff that how this is being done in 08:55.230 --> 08:56.310 case you forgot that. 08:56.310 --> 08:57.660 So there we go. 08:57.660 --> 09:04.050 So notice here, this is the foo and bar, this is actually the entire object which is acting as a payload. 09:04.050 --> 09:05.730 So this is the most important thing. 09:05.730 --> 09:06.990 So let's go ahead and work with that. 09:06.990 --> 09:11.250 Then we go ahead and mention a private key and then we won't be passing algorithm. 09:11.250 --> 09:13.320 We would be rather passing on that when it expires. 09:13.320 --> 09:14.970 So let's go ahead and work on with that. 09:15.300 --> 09:18.750 So first thing that we're going to do is let's go ahead and pass on. 09:18.750 --> 09:26.640 So as soon as you save any value inside the database, Mongoose or in general, MongoDB actually gives 09:26.640 --> 09:32.190 it a unique object ID and that object ID we can access by this variable user. 09:32.190 --> 09:35.310 And that's why we have created this and are holding that into a variable. 09:35.310 --> 09:37.950 Otherwise that simple user is just fine. 09:37.950 --> 09:42.390 We don't need to hold the reference somewhere, so let's go ahead and work on with that the way how 09:42.390 --> 09:47.010 we access it inside the database is saying whatever the object name and then the property name is. 09:47.010 --> 09:50.940 Underscore ID a little bit weird, but this is how it works on. 09:51.510 --> 09:56.580 So we're going to call this one because this is dot underscore ID is a little bit weird to me so we're 09:56.580 --> 09:59.820 going to go ahead and say that I want to hold this into a variable. 09:59.820 --> 10:08.220 So I'm going to go ahead and say call this one as user underscore ID remember this always this is the 10:08.220 --> 10:14.070 reference of the variable that this is what it has created and given me back the same user. 10:14.070 --> 10:18.870 So this user dot underscore ID is something that's coming up from the database itself. 10:18.900 --> 10:24.420 I found it a little bit weird to call it as DOT underscore ID, so I'm just renaming it as user underscore 10:24.420 --> 10:24.720 ID. 10:24.720 --> 10:26.430 You can just call it as it is as well. 10:26.700 --> 10:31.530 Now further down the road, just to show you all that we don't need it, but you can go ahead and store 10:31.530 --> 10:33.180 other information like email as well. 10:33.180 --> 10:38.250 What are the email we have passed on here so we can go ahead and you can also here say user dot email 10:38.250 --> 10:40.800 as well in case you want to extract it from the base itself. 10:40.800 --> 10:44.190 But this email and this email are just the same. 10:44.190 --> 10:45.510 So I'm going to go ahead and do that. 10:46.350 --> 10:48.870 Now comes up the information that is the private key. 10:48.870 --> 10:50.250 What is this private key? 10:50.250 --> 10:55.050 Now, this private key is really, really important because based on this, your token will be generated 10:55.050 --> 10:55.380 notice. 10:55.380 --> 10:57.510 It's a it's a secret or private key. 10:57.600 --> 11:01.980 Now, since this is super important, that's why you are going to see that everybody just say this is 11:01.980 --> 11:03.750 a secret key. 11:03.750 --> 11:08.610 And this secret key is entirely being used in all of throughout the application and you can name it 11:08.610 --> 11:09.210 as anything. 11:09.210 --> 11:12.050 This is my ae key. 11:12.050 --> 11:14.550 You name it, whatever you like, it doesn't really matter. 11:14.550 --> 11:19.770 You can make it more complex or something, but I like to keep it a long string with all the capital 11:19.770 --> 11:20.670 letters and all of that. 11:20.670 --> 11:22.080 So it's a combination of that. 11:22.260 --> 11:25.530 Okay, once this is being done, now I can go ahead and access that. 11:25.530 --> 11:30.150 In order to access that, I can hold it into a kind of a D structure that just like we have done in 11:30.150 --> 11:37.170 the past, or I can just go ahead and say directly process E and V dot, it's always better to copy 11:37.170 --> 11:39.930 this because I make a lot of typos. 11:39.960 --> 11:40.480 Okay. 11:40.920 --> 11:45.930 So the private key is also being passed on and now the final thing is passing on an object. 11:45.930 --> 11:50.700 Now this object can actually store it if you want to change the algorithm or you want to just process 11:50.700 --> 11:52.290 that when this should expire. 11:52.290 --> 11:58.350 So I'm going to write the only one which is expires in and mine is going to expire in two hour, which 11:58.350 --> 11:59.760 I think is a good enough time. 12:00.450 --> 12:00.910 Okay. 12:01.110 --> 12:04.860 Now this token is being created, so this whole part is being done. 12:04.860 --> 12:11.100 The token is being created now since my model actually allows me to simply say user dot token, I'm 12:11.100 --> 12:13.650 going to update that by saying simply token. 12:13.830 --> 12:18.180 Now, am I going to update this into the database as well? 12:18.210 --> 12:20.250 That is totally a strategy. 12:21.030 --> 12:26.640 Update or not, maybe you want to store that something into the database itself. 12:26.640 --> 12:28.950 You can again go ahead and save this into a database. 12:28.950 --> 12:33.090 And if somebody tries to access any resource, you can take that token. 12:33.090 --> 12:39.060 And even before kind of verifying that token, you can say that whether there is any token already existing 12:39.060 --> 12:42.840 in that user's property or not, otherwise you can just simply deny him. 12:42.840 --> 12:44.520 So again, there are a lot of strategies that can. 12:44.920 --> 12:46.510 And people can debate all of that. 12:47.380 --> 12:53.560 So once this is all being done, now this user that you are having is having a lot of information. 12:53.560 --> 12:56.170 So whenever it gives you back, it gives you all the information. 12:56.170 --> 12:59.560 So first name, last name, email, password, everything is coming back. 12:59.770 --> 13:02.200 So we need to take care of that situation as well. 13:02.710 --> 13:05.290 And we will be doing that, but not in this video. 13:05.290 --> 13:06.760 I wanted to show you more of that. 13:06.850 --> 13:07.180 Okay. 13:07.180 --> 13:13.330 So what we're going to do is simply resort status and the status is 201 because something has something 13:13.330 --> 13:19.150 new is created, and then we're going to simply use JSON instead of saying resort send and we're going 13:19.150 --> 13:24.490 to just go ahead and send this entire user to at least see that what is going on all about it. 13:24.970 --> 13:25.240 Okay. 13:25.300 --> 13:28.420 So this is a lot of stuff that is happening up. 13:29.470 --> 13:31.720 Quite a lot of stuff actually is going on. 13:31.720 --> 13:36.340 And notice here we are doing all of this and we are not using the promises here. 13:36.340 --> 13:38.680 So this is also going to create an issue. 13:38.710 --> 13:43.600 Now, what we need to do is we actually need to wrap it up inside the Try and Catch blog. 13:43.600 --> 13:45.430 I should have done that earlier. 13:45.760 --> 13:49.120 But again, this is the common issue that I will address in the next section. 13:49.120 --> 13:54.340 So I need to go ahead and cut all of this and wrap it up around the Try Catch blog, even the sending 13:54.340 --> 13:54.550 part. 13:54.550 --> 13:56.500 So let's cut this up right now. 13:56.500 --> 13:57.580 This is how it looks like. 13:57.580 --> 13:59.980 So I'm going to go ahead and say try catch. 14:00.310 --> 14:06.040 And this whole thing goes into the try and if anything goes wrong in the error, so we are going to 14:06.040 --> 14:08.050 go ahead and just let just console.log it. 14:08.050 --> 14:12.400 We are not handling handling the errors as of now, but we'll have a separate section on that. 14:12.760 --> 14:15.220 So let's go ahead and log this. 14:16.840 --> 14:18.640 And we're going to just drop the error. 14:19.900 --> 14:24.820 Again, just a quick reminder why we are using try and catch because all of this information of and 14:24.820 --> 14:28.240 all of this should either be happening into a promise. 14:28.240 --> 14:32.830 But since we are not using the promise, that's why we are using try and catch, which is at least one 14:32.830 --> 14:33.610 of the safe way. 14:34.240 --> 14:38.050 There is still one issue remaining up, so we're going to go ahead and fix it up. 14:38.410 --> 14:40.960 This is update or not in DB. 14:41.970 --> 14:43.830 Is totally for you as a reference. 14:43.830 --> 14:45.510 And there is another to do here. 14:45.510 --> 14:51.680 So I'm going to go ahead and mark this one to do handle password situation. 14:51.690 --> 14:53.670 Still, there is a situation on the password. 14:56.230 --> 14:57.040 Come on. 14:59.480 --> 15:00.120 There we go. 15:00.140 --> 15:02.030 So, yes, there is a password situation. 15:02.030 --> 15:06.320 I'm fully aware of it, but I'm not going to handle it without showing you what the problem actually 15:06.320 --> 15:06.770 is. 15:06.770 --> 15:08.810 So let's go ahead, move in the next video. 15:08.810 --> 15:11.210 Now, our at least the registered root is complete. 15:11.210 --> 15:12.440 Let's test that. 15:12.440 --> 15:16.430 And after testing it, let's see what situation we are in and then fix it up. 15:16.430 --> 15:18.320 Let's go ahead and catch up in the next video.