1
00:00:02,200 --> 00:00:08,050
Now it's important to understand how authentication works because if you're having a web development

2
00:00:08,050 --> 00:00:12,100
background, you might be used to authentication working a bit differently.

3
00:00:12,100 --> 00:00:17,910
So we have a server, Firebase in our case but that can be any server to which we talk from our React

4
00:00:17,920 --> 00:00:19,570
Native mobile app

5
00:00:19,570 --> 00:00:25,330
and this is the server which typically also authenticates us, so where we can send the email and the

6
00:00:25,330 --> 00:00:30,030
password the user entered to create a new user or to log a user in,

7
00:00:30,040 --> 00:00:32,940
so we send that auth data to the server.

8
00:00:32,940 --> 00:00:39,880
Now the server responds with something, for example with an error if the credentials are wrong or with

9
00:00:39,880 --> 00:00:46,870
a success response if they're correct and in a traditional web application, a server would then also

10
00:00:46,870 --> 00:00:53,550
store a so-called session on the server and return a session key to the front-end,

11
00:00:53,560 --> 00:00:59,620
so to the browser for example that basically allows the browser to find out that the user using this

12
00:00:59,620 --> 00:01:02,580
app in this browser is authenticated.

13
00:01:02,590 --> 00:01:08,820
Now this works a bit differently for mobile apps because there, you communicate with servers which are

14
00:01:08,840 --> 00:01:13,640
stateless, for example RESTful APIs or GraphQL APIs

15
00:01:13,930 --> 00:01:19,360
and there you don't really have a session because the server doesn't care about the individual clients,

16
00:01:19,420 --> 00:01:23,680
it doesn't save any data about whether you are authenticated or not,

17
00:01:24,280 --> 00:01:27,010
instead you work with so-called tokens.

18
00:01:27,010 --> 00:01:30,780
The idea is not too far away from the session idea.

19
00:01:31,030 --> 00:01:36,250
When you login and the server checks the e-mail and the password and determines that both is correct,

20
00:01:36,850 --> 00:01:38,680
the server creates a token,

21
00:01:38,680 --> 00:01:45,430
it uses a certain algorithm for that and it uses a key, a private key which only the server knows. This

22
00:01:45,430 --> 00:01:47,530
token is then returned to you,

23
00:01:47,530 --> 00:01:53,470
so to your app, for example to React Native mobile app and there you can store the token in some storage,

24
00:01:53,860 --> 00:01:56,010
for example in the Redux storage,

25
00:01:56,020 --> 00:02:00,700
so in memory, manage it with Redux in memory whilst your app is running.

26
00:02:00,910 --> 00:02:08,260
Now why do we need that token? For one, as long as we have that token, we can determine in the mobile app

27
00:02:08,290 --> 00:02:13,780
that the user is probably logged in and therefore forward the user from the authentication screen

28
00:02:13,780 --> 00:02:19,450
to our main app screen and so on and when the user clicks logout, we would simply delete that token

29
00:02:20,110 --> 00:02:25,630
but we also need that token for something else. On the server, as I mentioned we typically have certain

30
00:02:25,690 --> 00:02:31,600
resources, certain URLs which are only exposed to logged in users,

31
00:02:31,690 --> 00:02:37,860
so for example in our app, creating products is probably not something every user should be able to do

32
00:02:37,910 --> 00:02:43,720
and therefore if you want to send the request to such a protected resource, you need to attach that token

33
00:02:43,720 --> 00:02:50,500
to the request so that the server which created the token and which therefore can check with that private

34
00:02:50,500 --> 00:02:55,580
key whether the token is valid, so that the server can determine whether you have access or not.

35
00:02:55,660 --> 00:03:02,620
If you send a wrong token or an invalid token or no token at all, access will be denied and you get back

36
00:03:02,620 --> 00:03:05,090
an error. If you have a valid token

37
00:03:05,110 --> 00:03:11,050
and again the server is able to check whether the token is valid or not, you will be granted access and

38
00:03:11,050 --> 00:03:14,970
you can therefore then access the resources, write data, whatever it is.

39
00:03:15,070 --> 00:03:17,430
This is how authentication works

40
00:03:17,560 --> 00:03:19,560
and this is how we will implement it here.

41
00:03:19,570 --> 00:03:25,390
Now the good thing is Firebase which we're using as a dummy backend already has all the token creation

42
00:03:25,390 --> 00:03:29,460
user management stuff built-in, so we don't need to worry about that,

43
00:03:29,560 --> 00:03:34,210
we just need to send the right requests and then manage that token and we're good to go.