Maintenant, il est important de comprendre le fonctionnement de l'authentification, car si vous avez une expérience en développement Web,
vous pourriez être habitué à ce que l'authentification fonctionne un peu différemment.
Nous avons donc un serveur, Firebase dans notre cas, mais cela peut être n'importe quel serveur auquel nous parlons
depuis notre application mobile
React Native et c'est le serveur qui nous authentifie généralement, donc où nous pouvons envoyer l'e-mail et le
mot de passe que l'utilisateur a saisis pour créer un nouvel utilisateur ou pour se
connecter, nous envoyons donc ces données d'authentification au serveur.
Maintenant, le serveur répond avec quelque chose, par exemple avec une erreur si les informations d'identification sont incorrectes
ou avec une réponse de succès si elles sont correctes et dans une application Web traditionnelle, un serveur stockera
alors également une soi-disant session sur le serveur et retournera une clé de session pour le front-end, donc
pour le navigateur par exemple qui permet essentiellement au navigateur de savoir que l'utilisateur utilisant
cette application dans ce navigateur est authentifié.
Maintenant, cela fonctionne un peu différemment pour les applications mobiles, car là, vous communiquez avec des serveurs qui sont
sans état, par exemple les API RESTful ou les API GraphQL et là, vous
n'avez pas vraiment de session car le serveur ne se soucie pas des clients individuels, il ne
sauvegarde aucune donnée indiquant si vous êtes authentifié ou non, au lieu de
cela vous travaillez avec des soi-disant jetons.
L'idée n'est pas trop éloignée de l'idée de session.
Lorsque vous vous connectez et que le serveur vérifie l'e-mail et le mot de passe et détermine que les deux sont corrects, le serveur
crée un jeton, il utilise un certain algorithme
pour cela et il utilise une clé, une clé privée que seul le serveur connaît. Ce jeton vous est ensuite retourné, donc à votre
application, par exemple à l'application
mobile React Native et là vous pouvez stocker le jeton dans un certain stockage, par exemple dans
le stockage Redux, donc en mémoire,
gérez-le avec Redux en mémoire pendant que votre l'application est en cours d'exécution.
Maintenant, pourquoi avons-nous besoin de ce jeton? D'une part, tant que nous avons ce jeton, nous pouvons déterminer dans
l'application mobile que l'utilisateur est probablement connecté et donc transférer l'utilisateur de l'écran d'authentification à l'écran de notre
application principale et ainsi de suite et lorsque l'utilisateur clique sur déconnexion, nous supprimerait simplement ce jeton, mais nous
avons également besoin de ce jeton pour autre chose. Sur le serveur, comme je l'ai mentionné, nous
avons généralement certaines ressources, certaines URL qui ne sont exposées qu'aux utilisateurs connectés.Par exemple, dans notre application, la création
de produits n'est probablement pas quelque chose que chaque utilisateur devrait être en mesure de faire et donc si
vous le souhaitez envoyer la demande à une telle ressource protégée, vous devez attacher ce jeton à la
demande afin que le serveur qui a créé le jeton et qui peut donc vérifier avec cette clé privée si le
jeton est valide, afin que le serveur puisse déterminer si vous avez accès ou non.
Si vous envoyez un mauvais jeton ou un jeton invalide ou aucun jeton du tout, l'accès sera refusé et vous
obtenez une erreur. Si vous avez un
jeton valide et que le serveur est en mesure de vérifier si le jeton est valide ou non, vous aurez accès
et vous pourrez donc accéder aux ressources, écrire des données, quoi que ce soit.
C'est ainsi que l'authentification fonctionne et c'est ainsi
que nous allons l'implémenter ici.
Maintenant, la bonne chose est Firebase que nous utilisons comme backend factice a déjà tous les trucs de gestion des utilisateurs de
création de jetons intégrés, donc nous n'avons pas besoin de nous en soucier, nous
avons juste besoin d'envoyer les bonnes demandes, puis de gérer ce jeton et nous sommes prêts à partir.