Agora é importante entender como a autenticação funciona, porque se você tiver um histórico de desenvolvimento da web,
poderá estar acostumado a autenticação que funciona de maneira um pouco diferente.
Portanto, temos um servidor, o Firebase, no nosso caso, mas esse pode ser qualquer servidor com o qual
falamos em nosso aplicativo
móvel React Native e este é o servidor que normalmente também nos autentica, para que possamos enviar o
email e a senha que o usuário digitou para criar um novo usuário ou
efetuar login, enviamos esses dados de autenticação ao servidor.
Agora, o servidor responde com alguma coisa, por exemplo, com um erro se as credenciais estiverem erradas
ou com uma resposta bem-sucedida, se estiverem corretas. Em um aplicativo Web tradicional, um servidor também armazenaria
a chamada sessão no servidor e retornaria uma chave de sessão para o front-end, portanto, para o
navegador, por exemplo, que basicamente permite ao navegador descobrir que o usuário que está usando
este aplicativo neste navegador está autenticado.
Agora, isso funciona de maneira um pouco diferente para aplicativos móveis, porque você se comunica com servidores
sem estado, por exemplo, APIs RESTful ou APIs GraphQL e, na verdade, você
não tem uma sessão porque o servidor não se importa com os clientes individuais. não
salva dados sobre se você está autenticado ou não; em vez
disso, você trabalha com os chamados tokens.
A ideia não está muito longe da ideia da sessão.
Quando você efetua login e o servidor verifica o email e a senha e determina que ambos estão corretos, o servidor cria
um token, usa um determinado algoritmo para
isso e usa uma chave, uma chave privada que somente o servidor conhece. Em seguida, esse token é retornado a você, para o
seu aplicativo, por exemplo, para
o React Native mobile app e lá você pode armazenar o token em algum armazenamento, por exemplo,
no armazenamento Redux, para que na
memória, gerencie-o com o Redux na memória enquanto seu aplicativo está sendo executado.
Agora, por que precisamos desse token? Por um lado, desde que tenhamos esse token, podemos determinar no
aplicativo móvel que o usuário provavelmente está conectado e, portanto, encaminhar o usuário da tela de autenticação para
a tela principal do aplicativo e assim por diante. Quando o usuário clicar em logoff, simplesmente excluiria esse token,
mas também precisamos desse token para outra coisa. No servidor, como mencionei, normalmente temos
certos recursos, certos URLs que são expostos apenas a usuários logados. Por exemplo, em nosso aplicativo,
criar produtos provavelmente não é algo que todo usuário deve poder fazer e, portanto, se desejar enviar
a solicitação a um recurso protegido, você precisa anexar esse token à solicitação para que
o servidor que criou o token e, portanto, possa verificar com essa chave privada se o token é
válido, para que o servidor possa determinar se você possui acesso ou não.
Se você enviar um token errado ou inválido ou nenhum token, o acesso será negado e você
receberá um erro. Se você tiver
um token válido e, novamente, o servidor puder verificar se o token é válido ou não, você receberá
acesso e, portanto, poderá acessar os recursos, gravar dados, o que for.
É assim que a autenticação funciona e é
assim que vamos implementá-la aqui.
Agora, o bom é que o Firebase, que estamos usando como back-end fictício, já possui todo o material de gerenciamento
de usuários para criação de tokens, por isso não precisamos nos preocupar com
isso, basta enviar as solicitações corretas e gerenciar esse token e estamos prontos para ir.