1
00:00:00,500 --> 00:00:05,570
In the last section we did a discussion about what the decrypts library was doing for us.

2
00:00:05,610 --> 00:00:10,800
We only really spoke about the crypt in the context of creating a user account and we haven't really

3
00:00:10,800 --> 00:00:15,350
talked about the more important aspect which is how we compare a password in the future when the user

4
00:00:15,350 --> 00:00:16,680
is trying to sign in.

5
00:00:17,010 --> 00:00:21,750
So when we talk about that in the future you know how to assign a user in the decrypt stuff is going

6
00:00:21,750 --> 00:00:23,430
to start to make a lot more sense.

7
00:00:23,430 --> 00:00:26,090
So if it's still is kind of like I don't really know what's going on here.

8
00:00:26,100 --> 00:00:26,760
Don't sweat it.

9
00:00:26,760 --> 00:00:30,000
Once we talked about log in it's going to be a little bit more clear.

10
00:00:31,900 --> 00:00:36,420
So to continue on our application let's look at our asudden location controller.

11
00:00:36,640 --> 00:00:41,440
We've got these Sign-Up handler in here right now we can successfully sign a user up and create their

12
00:00:41,440 --> 00:00:42,360
account.

13
00:00:42,790 --> 00:00:48,670
And at the very bottom we left a point in here which we said that we want to respond Reclast and Kading

14
00:00:48,670 --> 00:00:50,200
that the user was created.

15
00:00:50,290 --> 00:00:51,700
And so we respond success.

16
00:00:51,700 --> 00:00:52,630
True.

17
00:00:53,140 --> 00:00:58,260
If you recall though this doesn't really fit the requirements of authentication that we had sent up

18
00:00:58,270 --> 00:01:00,390
for in the past.

19
00:01:00,430 --> 00:01:10,030
We were looking at a diagram and we said that when a user is signing in or signing up and we verify

20
00:01:10,030 --> 00:01:15,700
their credentials we said we would give them back in identifying piece of information to include on

21
00:01:15,700 --> 00:01:22,060
all future requests and they could then in the future use that identifying piece of information to follow

22
00:01:22,060 --> 00:01:24,810
up with making some number of requests.

23
00:01:24,820 --> 00:01:30,720
So inside of that inside the Sign-Up handler right here at the very end we're sending back just success

24
00:01:30,730 --> 00:01:33,920
true which is like pretty worthless right it's not really doing that much.

25
00:01:34,070 --> 00:01:35,320
We really want to send back.

26
00:01:35,380 --> 00:01:40,150
Is that identifying piece of information after a user signs up.

27
00:01:40,150 --> 00:01:43,420
We now consider them to be logged into our application.

28
00:01:43,510 --> 00:01:50,450
And so at this point in time we want to send back that identifying token keywords here being token.

29
00:01:50,460 --> 00:01:58,390
So in this section we're going to work at producing a token of sorts that the user can store and use

30
00:01:58,390 --> 00:02:01,180
in the future to make authenticated requests.

31
00:02:02,950 --> 00:02:07,360
So let's talk a little bit about the token that we're going to create the token that we're going to

32
00:02:07,360 --> 00:02:12,800
create is specifically called a Jason web tokin or JWT.

33
00:02:13,090 --> 00:02:17,340
Let's talk about how we're going to create the token and how we're going to make use of it.

34
00:02:17,980 --> 00:02:23,160
So this diagram right here shows two different phases in our applications lifecycle on the top.

35
00:02:23,170 --> 00:02:29,050
It's shown in the case of when a user is signing up or signing in and on the bottom we're showing what

36
00:02:29,050 --> 00:02:33,620
happens in the future when they try to make an authenticated request.

37
00:02:33,640 --> 00:02:37,880
So on the top we're saying that we're going to take a user's ID.

38
00:02:38,020 --> 00:02:42,490
So at this point in time we're going to assume that we've already verified their username and password

39
00:02:42,670 --> 00:02:45,310
or we've just created their user account you know everything looks good.

40
00:02:45,310 --> 00:02:46,910
We want to give them a token.

41
00:02:47,170 --> 00:02:49,470
So we're going to take the user's ID.

42
00:02:49,720 --> 00:02:56,140
We're going to combine it or encrypt it with some secret string that we are going to create very shortly

43
00:02:56,920 --> 00:03:01,830
and that produces a Jason web tokin or JWT.

44
00:03:02,170 --> 00:03:09,940
So in essence take a user id encrypt it with a string that produces a token that we can send back to

45
00:03:09,940 --> 00:03:11,030
the user.

46
00:03:11,200 --> 00:03:18,920
The user can then in the future include this token on request to make authenticated requests.

47
00:03:19,000 --> 00:03:25,990
So in the future if the user gives us a token we can decrypt it using our secret string.

48
00:03:26,110 --> 00:03:28,920
And that's going to result in the User ID.

49
00:03:29,050 --> 00:03:36,910
We can then verify this is user and so they have access to these different resources so they are now

50
00:03:36,910 --> 00:03:38,450
authenticated.

51
00:03:38,470 --> 00:03:43,960
The key here is that if the secret string is incorrect or some like you know someone malicious tries

52
00:03:43,960 --> 00:03:51,400
to decrypt our string or decrypt the token if they do not have the correct string or the correct secret

53
00:03:51,400 --> 00:03:54,520
here it is not going to result in a user ID.

54
00:03:54,610 --> 00:03:56,900
So that is where the security comes from.

55
00:03:56,980 --> 00:04:00,970
We have to make sure that we always keep our secret 100 percent secret.

56
00:04:00,970 --> 00:04:06,130
We never want to accidentally post this on our good hub or copy paste it to someone else.

57
00:04:06,130 --> 00:04:13,770
This string right here is absolutely paramount to our applications security.

58
00:04:13,810 --> 00:04:17,360
So one more time to watch this again and they will work on the implementation.

59
00:04:17,380 --> 00:04:19,519
We are going to create a Jason web token.

60
00:04:19,540 --> 00:04:24,960
The purpose of which is going to be authenticating users to create a token.

61
00:04:24,990 --> 00:04:32,590
Are you going to encrypt the user's ID with our secret string that is going to produce a web token in

62
00:04:32,590 --> 00:04:35,670
the future when someone wants to make an authenticated request.

63
00:04:35,680 --> 00:04:38,010
They're going to send us their token.

64
00:04:38,020 --> 00:04:44,500
We'll take that token we will decrypt it with our secret string and that will yield a user ID and we

65
00:04:44,500 --> 00:04:47,200
can then verify that this user exists.

66
00:04:47,200 --> 00:04:48,670
They are now signed in.

67
00:04:48,670 --> 00:04:52,020
They have access to you know so and so resources.

68
00:04:52,750 --> 00:04:57,250
All right so with this overview out of the way let's get started on the implementation and the next

69
00:04:57,250 --> 00:04:58,330
section.