1
00:00:02,200 --> 00:00:08,050
Agora é importante entender como a autenticação funciona, porque se você tiver um histórico de desenvolvimento da web,

2
00:00:08,050 --> 00:00:12,100
poderá estar acostumado a autenticação que funciona de maneira um pouco diferente.

3
00:00:12,100 --> 00:00:17,910
Portanto, temos um servidor, o Firebase, no nosso caso, mas esse pode ser qualquer servidor com o qual

4
00:00:17,920 --> 00:00:19,570
falamos em nosso aplicativo

5
00:00:19,570 --> 00:00:25,330
móvel React Native e este é o servidor que normalmente também nos autentica, para que possamos enviar o

6
00:00:25,330 --> 00:00:30,030
email e a senha que o usuário digitou para criar um novo usuário ou

7
00:00:30,040 --> 00:00:32,940
efetuar login, enviamos esses dados de autenticação ao servidor.

8
00:00:32,940 --> 00:00:39,880
Agora, o servidor responde com alguma coisa, por exemplo, com um erro se as credenciais estiverem erradas

9
00:00:39,880 --> 00:00:46,870
ou com uma resposta bem-sucedida, se estiverem corretas. Em um aplicativo Web tradicional, um servidor também armazenaria

10
00:00:46,870 --> 00:00:53,550
a chamada sessão no servidor e retornaria uma chave de sessão para o front-end, portanto, para o

11
00:00:53,560 --> 00:00:59,620
navegador, por exemplo, que basicamente permite ao navegador descobrir que o usuário que está usando

12
00:00:59,620 --> 00:01:02,580
este aplicativo neste navegador está autenticado.

13
00:01:02,590 --> 00:01:08,820
Agora, isso funciona de maneira um pouco diferente para aplicativos móveis, porque você se comunica com servidores

14
00:01:08,840 --> 00:01:13,640
sem estado, por exemplo, APIs RESTful ou APIs GraphQL e, na verdade, você

15
00:01:13,930 --> 00:01:19,360
não tem uma sessão porque o servidor não se importa com os clientes individuais. não

16
00:01:19,420 --> 00:01:23,680
salva dados sobre se você está autenticado ou não; em vez

17
00:01:24,280 --> 00:01:27,010
disso, você trabalha com os chamados tokens.

18
00:01:27,010 --> 00:01:30,780
A ideia não está muito longe da ideia da sessão.

19
00:01:31,030 --> 00:01:36,250
Quando você efetua login e o servidor verifica o email e a senha e determina que ambos estão corretos, o servidor cria

20
00:01:36,850 --> 00:01:38,680
um token, usa um determinado algoritmo para

21
00:01:38,680 --> 00:01:45,430
isso e usa uma chave, uma chave privada que somente o servidor conhece. Em seguida, esse token é retornado a você, para o

22
00:01:45,430 --> 00:01:47,530
seu aplicativo, por exemplo, para

23
00:01:47,530 --> 00:01:53,470
o React Native mobile app e lá você pode armazenar o token em algum armazenamento, por exemplo,

24
00:01:53,860 --> 00:01:56,010
no armazenamento Redux, para que na

25
00:01:56,020 --> 00:02:00,700
memória, gerencie-o com o Redux na memória enquanto seu aplicativo está sendo executado.

26
00:02:00,910 --> 00:02:08,260
Agora, por que precisamos desse token? Por um lado, desde que tenhamos esse token, podemos determinar no

27
00:02:08,290 --> 00:02:13,780
aplicativo móvel que o usuário provavelmente está conectado e, portanto, encaminhar o usuário da tela de autenticação para

28
00:02:13,780 --> 00:02:19,450
a tela principal do aplicativo e assim por diante. Quando o usuário clicar em logoff, simplesmente excluiria esse token,

29
00:02:20,110 --> 00:02:25,630
mas também precisamos desse token para outra coisa. No servidor, como mencionei, normalmente temos

30
00:02:25,690 --> 00:02:31,600
certos recursos, certos URLs que são expostos apenas a usuários logados. Por exemplo, em nosso aplicativo,

31
00:02:31,690 --> 00:02:37,860
criar produtos provavelmente não é algo que todo usuário deve poder fazer e, portanto, se desejar enviar

32
00:02:37,910 --> 00:02:43,720
a solicitação a um recurso protegido, você precisa anexar esse token à solicitação para que

33
00:02:43,720 --> 00:02:50,500
o servidor que criou o token e, portanto, possa verificar com essa chave privada se o token é

34
00:02:50,500 --> 00:02:55,580
válido, para que o servidor possa determinar se você possui acesso ou não.

35
00:02:55,660 --> 00:03:02,620
Se você enviar um token errado ou inválido ou nenhum token, o acesso será negado e você

36
00:03:02,620 --> 00:03:05,090
receberá um erro. Se você tiver

37
00:03:05,110 --> 00:03:11,050
um token válido e, novamente, o servidor puder verificar se o token é válido ou não, você receberá

38
00:03:11,050 --> 00:03:14,970
acesso e, portanto, poderá acessar os recursos, gravar dados, o que for.

39
00:03:15,070 --> 00:03:17,430
É assim que a autenticação funciona e é

40
00:03:17,560 --> 00:03:19,560
assim que vamos implementá-la aqui.

41
00:03:19,570 --> 00:03:25,390
Agora, o bom é que o Firebase, que estamos usando como back-end fictício, já possui todo o material de gerenciamento

42
00:03:25,390 --> 00:03:29,460
de usuários para criação de tokens, por isso não precisamos nos preocupar com

43
00:03:29,560 --> 00:03:34,210
isso, basta enviar as solicitações corretas e gerenciar esse token e estamos prontos para ir.