1
00:00:00,150 --> 00:00:06,630
In this lecture, we're going to discuss how authentication works, the next step for an application

2
00:00:06,630 --> 00:00:10,080
is to authenticate the user after they've registered an account.

3
00:00:10,410 --> 00:00:12,420
This step is entirely optional.

4
00:00:12,630 --> 00:00:15,510
It completely depends on the needs of your project.

5
00:00:15,720 --> 00:00:20,520
However, you'll find that most apps will log you in after creating an account.

6
00:00:21,030 --> 00:00:23,010
It's a common user experience.

7
00:00:23,220 --> 00:00:29,100
We're going to implement this experience for our users before we get into writing code.

8
00:00:29,220 --> 00:00:32,940
Let's understand how authentication works behind the scenes.

9
00:00:33,480 --> 00:00:38,370
First thing's first, we have to use our project as two different applications.

10
00:00:38,640 --> 00:00:45,600
We have the angular application we're building and then we have Firebase authentication is mainly handled

11
00:00:45,600 --> 00:00:46,440
on the server.

12
00:00:46,710 --> 00:00:49,380
In our case, this would be Firebase.

13
00:00:49,710 --> 00:00:56,640
Firebase can take care of hashing passwords, sending a confirmation email or storing the user's data.

14
00:00:57,000 --> 00:01:01,800
As for front end developers, we don't have to worry about these kinds of things.

15
00:01:02,340 --> 00:01:05,280
The role of the front end is relatively simple.

16
00:01:05,550 --> 00:01:07,980
We send the log in data to the server.

17
00:01:08,100 --> 00:01:12,330
The server responds with a token and then we store that token.

18
00:01:12,720 --> 00:01:14,760
There's not much else for us to do.

19
00:01:15,390 --> 00:01:21,960
Authentication tends to be the same across many backend solutions, even though we're using Firebase

20
00:01:21,960 --> 00:01:22,950
as our server.

21
00:01:23,130 --> 00:01:30,840
You can apply this process to almost any backend, regardless if it's PHP node or some other programming

22
00:01:30,840 --> 00:01:31,440
language.

23
00:01:32,040 --> 00:01:35,700
Let's break down the authentication process step by step.

24
00:01:36,090 --> 00:01:40,620
Our angular application will send the user's login data to Firebase.

25
00:01:40,890 --> 00:01:42,480
We're familiar with this step.

26
00:01:42,750 --> 00:01:45,390
We performed it at the start of this section.

27
00:01:46,140 --> 00:01:49,320
Firebase will take care of authenticating the user.

28
00:01:49,560 --> 00:01:53,610
It'll check if a user exists with the credentials we sent over.

29
00:01:53,940 --> 00:01:58,620
If the authentication is successful, Firebase will generate a token.

30
00:01:59,040 --> 00:02:05,700
The token is what's sent back as the response tokens typically come in the form of a unique stream.

31
00:02:06,300 --> 00:02:08,550
Storage of the token is essential.

32
00:02:08,880 --> 00:02:12,570
There are various methods at our disposal under the hood.

33
00:02:12,810 --> 00:02:15,600
Firebase uses extended DB.

34
00:02:15,900 --> 00:02:20,400
It's an API for storing structured data on the user's browsers.

35
00:02:20,700 --> 00:02:23,370
This API is shipped with browsers.

36
00:02:23,610 --> 00:02:26,700
We don't need to enable this feature to start using it.

37
00:02:26,940 --> 00:02:28,650
It works out of the box.

38
00:02:29,190 --> 00:02:33,690
After storing the token, we can send it to Firebase with our requests.

39
00:02:33,990 --> 00:02:37,470
Firebase will verify the user by checking the token.

40
00:02:37,830 --> 00:02:41,940
This process happens automatically whenever we send a token.

41
00:02:42,270 --> 00:02:48,420
Since tokens are unique, we don't have to worry about a user's data being manipulated without their

42
00:02:48,420 --> 00:02:49,050
permission.

43
00:02:49,680 --> 00:02:53,160
We don't need to rescind the authentication info again.

44
00:02:53,490 --> 00:02:54,990
The token will suffice.

45
00:02:55,260 --> 00:02:57,750
This is just an overview of how things work.

46
00:02:58,020 --> 00:03:00,840
I'll get into specifics later in this section.

47
00:03:01,110 --> 00:03:05,490
It may seem like a lot to do, but it's rather simple and easy to implement.

48
00:03:05,520 --> 00:03:12,330
Once you see how it's done, the overall process I'm talking about is called stateless authentication.

49
00:03:12,720 --> 00:03:14,760
You may have heard of this term before.

50
00:03:15,000 --> 00:03:16,440
If not, that's fine.

51
00:03:16,710 --> 00:03:17,700
Let's talk about it.

52
00:03:18,030 --> 00:03:23,670
Traditionally, applications kept track of users by using a feature called Sessions.

53
00:03:24,090 --> 00:03:26,070
Sessions are stored on the server.

54
00:03:26,370 --> 00:03:32,610
The server actively knows who is logged in when the server keeps track of authenticated users.

55
00:03:32,790 --> 00:03:35,640
This is what's called stateful authentication.

56
00:03:35,970 --> 00:03:41,010
However, in our case, Firebase will not keep track of who's logged in.

57
00:03:41,730 --> 00:03:47,790
Instead, we're going to use tokens to verify the user for every request we send.

58
00:03:47,970 --> 00:03:49,770
We will also send the token.

59
00:03:50,100 --> 00:03:56,760
Firebase will use the token to confirm that the user is who they say they are because the server doesn't

60
00:03:56,760 --> 00:03:58,620
keep track of who's logged in.

61
00:03:58,830 --> 00:04:01,530
This is what's called stateless authentication.

62
00:04:02,100 --> 00:04:07,440
It's very common to implement stateless authentication for single page applications.

63
00:04:07,740 --> 00:04:12,630
While sessions are still practical, it's much easier to work with tokens.