1
00:00:00,330 --> 00:00:02,370
All right, we check for empty values now.

2
00:00:02,940 --> 00:00:07,140
Well, now we need to create a JSON Web token and send it back.

3
00:00:07,440 --> 00:00:12,730
But before we do that, let's back up a little bit and take a look at the big picture one more time.

4
00:00:13,140 --> 00:00:16,770
So far, we have been setting up all our roots in falling fashion.

5
00:00:16,980 --> 00:00:23,160
As long as the end point exists, user just needs to make a request and our server will send a response.

6
00:00:23,610 --> 00:00:24,960
But that's about the change.

7
00:00:25,350 --> 00:00:32,310
From now on, we'll have two types of roots, republic ones accessible by anyone and restricted once

8
00:00:32,610 --> 00:00:38,550
accessible only with correct signed JWT or Jasanoff token.

9
00:00:39,000 --> 00:00:40,050
So back to our app.

10
00:00:40,590 --> 00:00:46,800
If the user provides correct credentials, meaning in our case, of course, those are just some values

11
00:00:46,800 --> 00:00:52,100
in the user name and password we send back signed Jason Watt token.

12
00:00:52,230 --> 00:00:59,910
And in order to access that, he or she basically, if content needs to provide the same token, otherwise

13
00:00:59,910 --> 00:01:02,610
we'll kick it back with an error response.

14
00:01:02,700 --> 00:01:07,680
And before we analyze the structure of the Jason Web token, let's talk about some big picture things

15
00:01:07,680 --> 00:01:08,070
first.

16
00:01:08,460 --> 00:01:10,310
And let's start with general concept.

17
00:01:10,770 --> 00:01:15,600
Jason, Web token is just a way to exchange data between two parties.

18
00:01:15,900 --> 00:01:21,230
And probably the most common example for such parties is a front, an app on our API.

19
00:01:21,750 --> 00:01:31,290
Not why using JWT is far better than just some random string, simply because JWT has a security feature

20
00:01:31,770 --> 00:01:35,180
where we can be sure about the integrity of our data.

21
00:01:35,610 --> 00:01:42,990
If the token passes the validation, it means it's the same token we sent to the client and the data

22
00:01:42,990 --> 00:01:43,930
wasn't tampered with.

23
00:01:44,130 --> 00:01:47,540
Second, for now, don't worry how and where the front end will start token.

24
00:01:47,880 --> 00:01:50,370
I'll discuss it in more detail and few videos.

25
00:01:50,700 --> 00:01:58,440
And third, please keep in mind that one of the features of HTP is that it is stateless and that simply

26
00:01:58,440 --> 00:02:05,910
means that server does not know or you can think does not remember any previous requests sent by the

27
00:02:05,910 --> 00:02:06,810
same client.

28
00:02:07,230 --> 00:02:14,880
And as a result, yes, even after the first, second or even the two hundred successful dashboard request,

29
00:02:15,180 --> 00:02:18,660
front end will still need to provide the valid token.

30
00:02:18,960 --> 00:02:21,030
Otherwise the access will be denied.