Ahora es importante comprender cómo funciona la autenticación porque si tiene experiencia en desarrollo web, es posible que
esté acostumbrado a que la autenticación funcione de manera un poco diferente.
Por lo tanto, tenemos un servidor, Firebase en nuestro caso, pero puede ser cualquier servidor con el que hablemos
desde nuestra aplicación móvil React
Native y este es el servidor que generalmente también nos autentica, para que podamos enviar el correo electrónico y
la contraseña que ingresó el usuario para crear un nuevo usuario o para iniciar sesión, de
modo que enviamos esos datos de autenticación al servidor.
Ahora el servidor responde con algo, por ejemplo, con un error si las credenciales son incorrectas o
con una respuesta exitosa si son correctas y en una aplicación web tradicional, un servidor también almacenaría una
llamada sesión en el servidor y devolvería una clave de sesión para el front-end, por ejemplo, para
el navegador que básicamente le permite al navegador descubrir que el usuario que usa esta
aplicación en este navegador está autenticado.
Ahora, esto funciona un poco diferente para las aplicaciones móviles porque allí, te comunicas con servidores
que no tienen estado, por ejemplo, API RESTful o GraphQL API y allí
realmente no tienes una sesión porque al servidor no le importan los clientes individuales,
no guarda ningún dato sobre si está autenticado o no, sino
que trabaja con los llamados tokens.
La idea no está muy lejos de la idea de la sesión.
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
un token, usa un cierto algoritmo para
eso y usa una clave, una clave privada que solo el servidor conoce. Este token se le devuelve a usted, por lo tanto,
a su aplicación, por ejemplo,
a la aplicación móvil React Native y allí puede almacenar el token en algún almacenamiento, por ejemplo, en
el almacenamiento de Redux, así que en
la memoria, adminístrelo con Redux en la memoria mientras su La aplicación se está ejecutando.
Ahora, ¿por qué necesitamos esa ficha? Por un lado, siempre que tengamos ese token, podemos determinar en la aplicación móvil
que el usuario probablemente haya iniciado sesión y, por lo tanto, reenviar al usuario desde la pantalla de autenticación a
nuestra pantalla principal de la aplicación y así sucesivamente, y cuando el usuario hace clic en cerrar sesión, simplemente eliminaría ese
token pero también necesitamos ese token para otra cosa. En el servidor, como mencioné, generalmente tenemos
ciertos recursos, ciertas URL que solo están expuestas a los usuarios registrados, por lo que, por ejemplo, en
nuestra aplicación, crear productos probablemente no sea algo que todos los usuarios deberían poder hacer y, por lo tanto,
si lo desea enviar la solicitud a un recurso protegido de este tipo, debe adjuntar ese token a
la solicitud para que el servidor que creó el token y, por lo tanto, pueda verificar con esa clave privada si
el token es válido, para que el servidor pueda determinar si tiene acceso o no.
Si envía un token incorrecto o un token inválido o ningún token, el acceso será denegado y
recibirá un error. Si tiene un
token válido y nuevamente el servidor puede verificar si el token es válido o no, se le otorgará acceso y,
por lo tanto, podrá acceder a los recursos, escribir datos, lo que sea.
Así es como funciona la autenticación y así
es como la implementaremos aquí.
Ahora, lo bueno es que Firebase, que estamos utilizando como backend ficticio, ya tiene todo el material de administración de usuarios
de creación de tokens incorporado, por lo que no debemos preocuparnos por eso, solo
tenemos que enviar las solicitudes correctas y luego administrar esa ficha y estamos listos para irnos.