1
00:00:02,200 --> 00:00:08,050
Ahora es importante comprender cómo funciona la autenticación porque si tiene experiencia en desarrollo web, es posible que

2
00:00:08,050 --> 00:00:12,100
esté acostumbrado a que la autenticación funcione de manera un poco diferente.

3
00:00:12,100 --> 00:00:17,910
Por lo tanto, tenemos un servidor, Firebase en nuestro caso, pero puede ser cualquier servidor con el que hablemos

4
00:00:17,920 --> 00:00:19,570
desde nuestra aplicación móvil React

5
00:00:19,570 --> 00:00:25,330
Native y este es el servidor que generalmente también nos autentica, para que podamos enviar el correo electrónico y

6
00:00:25,330 --> 00:00:30,030
la contraseña que ingresó el usuario para crear un nuevo usuario o para iniciar sesión, de

7
00:00:30,040 --> 00:00:32,940
modo que enviamos esos datos de autenticación al servidor.

8
00:00:32,940 --> 00:00:39,880
Ahora el servidor responde con algo, por ejemplo, con un error si las credenciales son incorrectas o

9
00:00:39,880 --> 00:00:46,870
con una respuesta exitosa si son correctas y en una aplicación web tradicional, un servidor también almacenaría una

10
00:00:46,870 --> 00:00:53,550
llamada sesión en el servidor y devolvería una clave de sesión para el front-end, por ejemplo, para

11
00:00:53,560 --> 00:00:59,620
el navegador que básicamente le permite al navegador descubrir que el usuario que usa esta

12
00:00:59,620 --> 00:01:02,580
aplicación en este navegador está autenticado.

13
00:01:02,590 --> 00:01:08,820
Ahora, esto funciona un poco diferente para las aplicaciones móviles porque allí, te comunicas con servidores

14
00:01:08,840 --> 00:01:13,640
que no tienen estado, por ejemplo, API RESTful o GraphQL API y allí

15
00:01:13,930 --> 00:01:19,360
realmente no tienes una sesión porque al servidor no le importan los clientes individuales,

16
00:01:19,420 --> 00:01:23,680
no guarda ningún dato sobre si está autenticado o no, sino

17
00:01:24,280 --> 00:01:27,010
que trabaja con los llamados tokens.

18
00:01:27,010 --> 00:01:30,780
La idea no está muy lejos de la idea de la sesión.

19
00:01:31,030 --> 00:01:36,250
Cuando inicia sesión y el servidor verifica el correo electrónico y la contraseña y determina que ambos son correctos, el servidor crea

20
00:01:36,850 --> 00:01:38,680
un token, usa un cierto algoritmo para

21
00:01:38,680 --> 00:01:45,430
eso y usa una clave, una clave privada que solo el servidor conoce. Este token se le devuelve a usted, por lo tanto,

22
00:01:45,430 --> 00:01:47,530
a su aplicación, por ejemplo,

23
00:01:47,530 --> 00:01:53,470
a la aplicación móvil React Native y allí puede almacenar el token en algún almacenamiento, por ejemplo, en

24
00:01:53,860 --> 00:01:56,010
el almacenamiento de Redux, así que en

25
00:01:56,020 --> 00:02:00,700
la memoria, adminístrelo con Redux en la memoria mientras su La aplicación se está ejecutando.

26
00:02:00,910 --> 00:02:08,260
Ahora, ¿por qué necesitamos esa ficha? Por un lado, siempre que tengamos ese token, podemos determinar en la aplicación móvil

27
00:02:08,290 --> 00:02:13,780
que el usuario probablemente haya iniciado sesión y, por lo tanto, reenviar al usuario desde la pantalla de autenticación a

28
00:02:13,780 --> 00:02:19,450
nuestra pantalla principal de la aplicación y así sucesivamente, y cuando el usuario hace clic en cerrar sesión, simplemente eliminaría ese

29
00:02:20,110 --> 00:02:25,630
token pero también necesitamos ese token para otra cosa. En el servidor, como mencioné, generalmente tenemos

30
00:02:25,690 --> 00:02:31,600
ciertos recursos, ciertas URL que solo están expuestas a los usuarios registrados, por lo que, por ejemplo, en

31
00:02:31,690 --> 00:02:37,860
nuestra aplicación, crear productos probablemente no sea algo que todos los usuarios deberían poder hacer y, por lo tanto,

32
00:02:37,910 --> 00:02:43,720
si lo desea enviar la solicitud a un recurso protegido de este tipo, debe adjuntar ese token a

33
00:02:43,720 --> 00:02:50,500
la solicitud para que el servidor que creó el token y, por lo tanto, pueda verificar con esa clave privada si

34
00:02:50,500 --> 00:02:55,580
el token es válido, para que el servidor pueda determinar si tiene acceso o no.

35
00:02:55,660 --> 00:03:02,620
Si envía un token incorrecto o un token inválido o ningún token, el acceso será denegado y

36
00:03:02,620 --> 00:03:05,090
recibirá un error. Si tiene un

37
00:03:05,110 --> 00:03:11,050
token válido y nuevamente el servidor puede verificar si el token es válido o no, se le otorgará acceso y,

38
00:03:11,050 --> 00:03:14,970
por lo tanto, podrá acceder a los recursos, escribir datos, lo que sea.

39
00:03:15,070 --> 00:03:17,430
Así es como funciona la autenticación y así

40
00:03:17,560 --> 00:03:19,560
es como la implementaremos aquí.

41
00:03:19,570 --> 00:03:25,390
Ahora, lo bueno es que Firebase, que estamos utilizando como backend ficticio, ya tiene todo el material de administración de usuarios

42
00:03:25,390 --> 00:03:29,460
de creación de tokens incorporado, por lo que no debemos preocuparnos por eso, solo

43
00:03:29,560 --> 00:03:34,210
tenemos que enviar las solicitudes correctas y luego administrar esa ficha y estamos listos para irnos.