1
00:00:02,200 --> 00:00:08,050
Maintenant, il est important de comprendre le fonctionnement de l'authentification, car si vous avez une expérience en développement Web,

2
00:00:08,050 --> 00:00:12,100
vous pourriez être habitué à ce que l'authentification fonctionne un peu différemment.

3
00:00:12,100 --> 00:00:17,910
Nous avons donc un serveur, Firebase dans notre cas, mais cela peut être n'importe quel serveur auquel nous parlons

4
00:00:17,920 --> 00:00:19,570
depuis notre application mobile

5
00:00:19,570 --> 00:00:25,330
React Native et c'est le serveur qui nous authentifie généralement, donc où nous pouvons envoyer l'e-mail et le

6
00:00:25,330 --> 00:00:30,030
mot de passe que l'utilisateur a saisis pour créer un nouvel utilisateur ou pour se

7
00:00:30,040 --> 00:00:32,940
connecter, nous envoyons donc ces données d'authentification au serveur.

8
00:00:32,940 --> 00:00:39,880
Maintenant, le serveur répond avec quelque chose, par exemple avec une erreur si les informations d'identification sont incorrectes

9
00:00:39,880 --> 00:00:46,870
ou avec une réponse de succès si elles sont correctes et dans une application Web traditionnelle, un serveur stockera

10
00:00:46,870 --> 00:00:53,550
alors également une soi-disant session sur le serveur et retournera une clé de session pour le front-end, donc

11
00:00:53,560 --> 00:00:59,620
pour le navigateur par exemple qui permet essentiellement au navigateur de savoir que l'utilisateur utilisant

12
00:00:59,620 --> 00:01:02,580
cette application dans ce navigateur est authentifié.

13
00:01:02,590 --> 00:01:08,820
Maintenant, cela fonctionne un peu différemment pour les applications mobiles, car là, vous communiquez avec des serveurs qui sont

14
00:01:08,840 --> 00:01:13,640
sans état, par exemple les API RESTful ou les API GraphQL et là, vous

15
00:01:13,930 --> 00:01:19,360
n'avez pas vraiment de session car le serveur ne se soucie pas des clients individuels, il ne

16
00:01:19,420 --> 00:01:23,680
sauvegarde aucune donnée indiquant si vous êtes authentifié ou non, au lieu de

17
00:01:24,280 --> 00:01:27,010
cela vous travaillez avec des soi-disant jetons.

18
00:01:27,010 --> 00:01:30,780
L'idée n'est pas trop éloignée de l'idée de session.

19
00:01:31,030 --> 00:01:36,250
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

20
00:01:36,850 --> 00:01:38,680
crée un jeton, il utilise un certain algorithme

21
00:01:38,680 --> 00:01:45,430
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

22
00:01:45,430 --> 00:01:47,530
application, par exemple à l'application

23
00:01:47,530 --> 00:01:53,470
mobile React Native et là vous pouvez stocker le jeton dans un certain stockage, par exemple dans

24
00:01:53,860 --> 00:01:56,010
le stockage Redux, donc en mémoire,

25
00:01:56,020 --> 00:02:00,700
gérez-le avec Redux en mémoire pendant que votre l'application est en cours d'exécution.

26
00:02:00,910 --> 00:02:08,260
Maintenant, pourquoi avons-nous besoin de ce jeton? D'une part, tant que nous avons ce jeton, nous pouvons déterminer dans

27
00:02:08,290 --> 00:02:13,780
l'application mobile que l'utilisateur est probablement connecté et donc transférer l'utilisateur de l'écran d'authentification à l'écran de notre

28
00:02:13,780 --> 00:02:19,450
application principale et ainsi de suite et lorsque l'utilisateur clique sur déconnexion, nous supprimerait simplement ce jeton, mais nous

29
00:02:20,110 --> 00:02:25,630
avons également besoin de ce jeton pour autre chose. Sur le serveur, comme je l'ai mentionné, nous

30
00:02:25,690 --> 00:02:31,600
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

31
00:02:31,690 --> 00:02:37,860
de produits n'est probablement pas quelque chose que chaque utilisateur devrait être en mesure de faire et donc si

32
00:02:37,910 --> 00:02:43,720
vous le souhaitez envoyer la demande à une telle ressource protégée, vous devez attacher ce jeton à la

33
00:02:43,720 --> 00:02:50,500
demande afin que le serveur qui a créé le jeton et qui peut donc vérifier avec cette clé privée si le

34
00:02:50,500 --> 00:02:55,580
jeton est valide, afin que le serveur puisse déterminer si vous avez accès ou non.

35
00:02:55,660 --> 00:03:02,620
Si vous envoyez un mauvais jeton ou un jeton invalide ou aucun jeton du tout, l'accès sera refusé et vous

36
00:03:02,620 --> 00:03:05,090
obtenez une erreur. Si vous avez un

37
00:03:05,110 --> 00:03:11,050
jeton valide et que le serveur est en mesure de vérifier si le jeton est valide ou non, vous aurez accès

38
00:03:11,050 --> 00:03:14,970
et vous pourrez donc accéder aux ressources, écrire des données, quoi que ce soit.

39
00:03:15,070 --> 00:03:17,430
C'est ainsi que l'authentification fonctionne et c'est ainsi

40
00:03:17,560 --> 00:03:19,560
que nous allons l'implémenter ici.

41
00:03:19,570 --> 00:03:25,390
Maintenant, la bonne chose est Firebase que nous utilisons comme backend factice a déjà tous les trucs de gestion des utilisateurs de

42
00:03:25,390 --> 00:03:29,460
création de jetons intégrés, donc nous n'avons pas besoin de nous en soucier, nous

43
00:03:29,560 --> 00:03:34,210
avons juste besoin d'envoyer les bonnes demandes, puis de gérer ce jeton et nous sommes prêts à partir.