1 00:00:00,210 --> 00:00:05,640 In the previous video, we have made some changes inside our project, which will help us generating 2 00:00:05,640 --> 00:00:13,830 the JWT token like importing the dependencies inside the bombed out example, disabling the CSR of making 3 00:00:13,830 --> 00:00:21,480 the configurations inside cards along with the stopping the default generated token by leveraging session 4 00:00:21,480 --> 00:00:22,500 creation policy. 5 00:00:22,770 --> 00:00:26,970 So now in this video, let's try to create two filters. 6 00:00:27,150 --> 00:00:35,280 One needs to generate the token and other one is to validate the JWT token for each and every request 7 00:00:35,280 --> 00:00:36,730 that is coming from the client. 8 00:00:36,900 --> 00:00:44,910 So to achieve this first, I create a folder with the name JWT Token Generator Filter. 9 00:00:45,090 --> 00:00:52,440 So you can see here this filter extends once request filter, which indicates that this will that is 10 00:00:52,440 --> 00:00:55,940 going to run only once per each request. 11 00:00:56,070 --> 00:01:04,200 And at the same time, I also read the method should not filter and implement the logic that my filter 12 00:01:04,200 --> 00:01:11,970 should be executed only during the login request, since inside my application slash user is a login 13 00:01:11,970 --> 00:01:12,650 request. 14 00:01:12,660 --> 00:01:22,620 But I have mentioned that whenever my part is not equal to slash user, then should not filter or should 15 00:01:22,620 --> 00:01:29,520 not apply my filter, which will make sure that this filter will get executed only when the user trying 16 00:01:29,520 --> 00:01:31,640 to login into my application. 17 00:01:31,650 --> 00:01:35,940 So the logic of generating the token is present inside this matter. 18 00:01:36,210 --> 00:01:44,310 Where I am going to configure this filter for authentication is successful inside spring security framework 19 00:01:44,310 --> 00:01:47,940 and I'm going to configure this as an after filter. 20 00:01:48,090 --> 00:01:53,820 So once authentication is successful, I can get the authentication values from the security contacts 21 00:01:53,820 --> 00:01:54,360 holder. 22 00:01:54,480 --> 00:02:02,640 And by leveraging a secret key that I'm maintaining inside my back and somewhere along with the algorithm, 23 00:02:02,790 --> 00:02:05,610 I'm going to build a JWT token. 24 00:02:05,850 --> 00:02:10,979 And inside that JWT token, I'm going to set a lot of information. 25 00:02:11,160 --> 00:02:15,210 One is who is the issuer of that JWT token? 26 00:02:15,510 --> 00:02:17,340 What is the subject of the token? 27 00:02:17,460 --> 00:02:21,150 And at the same time claims we can set any number of claims. 28 00:02:21,420 --> 00:02:25,920 Claim is a value that goes inside our payload. 29 00:02:26,190 --> 00:02:31,350 And these are the information that you want to share to the other people. 30 00:02:31,440 --> 00:02:34,950 Are you want to store for us and for future reference. 31 00:02:35,040 --> 00:02:41,940 So one value that I'm going to put inside my token is the user name, which I get based upon the authentication 32 00:02:42,030 --> 00:02:42,660 object. 33 00:02:42,660 --> 00:02:49,180 And the other one is what are the authorities of the logged in user posts that I'm also going to set? 34 00:02:49,230 --> 00:02:52,680 What is the issue at the time for the token? 35 00:02:52,950 --> 00:02:57,390 And we can also set an expiration of that token to make it simple. 36 00:02:57,700 --> 00:03:01,110 I'm going to give a smaller milliseconds value. 37 00:03:01,260 --> 00:03:10,680 So thirty thousand milliseconds means this token will expire within 30 seconds and you can see the JWT 38 00:03:10,680 --> 00:03:13,080 beauty while violating the token. 39 00:03:13,380 --> 00:03:19,760 JWT will make sure that if the token is expires, it will throw an error to the user. 40 00:03:19,770 --> 00:03:25,830 So lastly, we have to sign it with the key based upon our algorithm and secret key. 41 00:03:26,100 --> 00:03:34,650 And at last we call compact matter to generate a JWT with header body and the signature key. 42 00:03:34,710 --> 00:03:43,770 So once I had that JWT encoded values along with my signature key, I am going to set that inside my 43 00:03:43,770 --> 00:03:47,640 response header with the value authorization. 44 00:03:47,640 --> 00:03:54,820 So this is the header that we configure inside our cards configurations to allow to send it to the UI 45 00:03:54,840 --> 00:03:55,500 application. 46 00:03:55,650 --> 00:04:04,050 So this filter will make sure to generate the JWT token when our user tried to login into my application. 47 00:04:04,050 --> 00:04:09,770 Next, I have to write one more filter to validate this data. 48 00:04:10,200 --> 00:04:15,240 Token that card generator for all the requests other than the login. 49 00:04:15,360 --> 00:04:21,930 The fact that I am going to write a new filter with the name JWT Token Validator Filter. 50 00:04:22,050 --> 00:04:27,810 So as you can expect, this filter also extends once per request filter. 51 00:04:27,960 --> 00:04:34,860 And I am going to configure this filter as a before authorization and authentication because since already 52 00:04:34,860 --> 00:04:39,630 authentication is happening, we have to make sure the token is compromised. 53 00:04:39,750 --> 00:04:45,150 We need to invalidate the request and send it to the UI application. 54 00:04:45,150 --> 00:04:52,260 So the logic here, you can see I also have implemented should not filter, which indicates that this 55 00:04:52,260 --> 00:04:58,680 filter should not be applied for the login request, which is user y for all other parts. 56 00:04:58,860 --> 00:04:59,940 This filter has to be. 57 00:05:00,030 --> 00:05:03,410 Apply when this filter is getting executed, are you? 58 00:05:03,440 --> 00:05:11,410 The application has to send the token value inside the request header with the same name authorization. 59 00:05:11,510 --> 00:05:19,670 So I'm going to populate that value from my header once I have the JWT token with the same secret key 60 00:05:19,670 --> 00:05:27,890 and algorithm that we used before, we are going to generate a new hash value compared with the already 61 00:05:27,890 --> 00:05:34,160 hash value present inside the JWT token to make sure that the values are not amper. 62 00:05:34,310 --> 00:05:42,080 If there is any issue happens during this code of execution, I'll get an exception and I'm going to 63 00:05:42,080 --> 00:05:45,100 return the invalid token received to the printer. 64 00:05:45,380 --> 00:05:52,250 If everything goes well, what I'm going to do is I'm going to take the username and authorities from 65 00:05:52,250 --> 00:05:59,030 the token and build the new authentication object and set it into the security context. 66 00:05:59,050 --> 00:06:07,370 Holder, you can see here my back in server is not storing anything based upon the JWT token. 67 00:06:07,640 --> 00:06:14,450 Every time I generally to authenticate an object without actually looking into the database for the 68 00:06:14,450 --> 00:06:19,970 credentials and validating the user based upon the JWT token values. 69 00:06:20,110 --> 00:06:23,750 And I think that integration object inside my security contacts. 70 00:06:23,780 --> 00:06:30,770 Holder So once my code execution passes this filter, it will go to the business logic and my spring 71 00:06:31,010 --> 00:06:38,090 security framework will make sure that if all the authorities associated to that user is proper, it 72 00:06:38,090 --> 00:06:39,560 will allow the execution. 73 00:06:39,770 --> 00:06:48,020 But if someone amperes this user name or authorities, obviously this code of execution will fail and 74 00:06:48,020 --> 00:06:49,550 will get an exception. 75 00:06:49,700 --> 00:06:58,640 And you can see this past clumsier method will throw exceptions related to expired JWT exception. 76 00:06:58,880 --> 00:07:01,330 Like Venner, our token is expired. 77 00:07:01,340 --> 00:07:06,270 This exception will come and support that MusclePharm signature illegal. 78 00:07:06,440 --> 00:07:10,970 All these exceptions will be thrown in the case of AMPA. 79 00:07:11,120 --> 00:07:14,960 So now we made the changes to create the filters. 80 00:07:15,110 --> 00:07:20,900 Let's try to configure these filters inside spring security configurations for the same. 81 00:07:20,900 --> 00:07:28,790 I go to the project security config and we already created previously some filters at the same place 82 00:07:28,790 --> 00:07:31,490 and going to add the new regenerator filters. 83 00:07:31,610 --> 00:07:35,270 And you can see here how are the newly generated filters? 84 00:07:35,420 --> 00:07:43,610 JWT token generator filter will be used to generate the tokens and that will get executer after the 85 00:07:43,610 --> 00:07:49,330 basic authentication filter completes and it will exist only during the logging operation. 86 00:07:49,610 --> 00:07:58,060 And similarly, JWT token validator filter will be executed before the authentication for each request 87 00:07:58,190 --> 00:08:03,350 other than the login to make sure the token validation is successful or not. 88 00:08:03,500 --> 00:08:06,830 So now we have made all the required changes and the backend. 89 00:08:07,190 --> 00:08:16,220 But on the front end also we have to capture this authentication at their value and we need to make 90 00:08:16,220 --> 00:08:23,270 sure that every request that is coming to the backend as to how that value present inside the header 91 00:08:23,540 --> 00:08:31,220 to achieve the same, let's try to make some changes on the inside code, also to send the authorization 92 00:08:31,220 --> 00:08:38,419 JWT token as part of the header inside request every time my client application is making a request 93 00:08:38,419 --> 00:08:39,260 to the back backend. 94 00:08:39,500 --> 00:08:41,419 Thank you and see you in the next release by.