Choisir une stratégie d’authentification
Objectif : Déterminer si les utilisateurs du service de commandes doivent être authentifiés par session ou par jeton, selon leurs clients et les contraintes d’exploitation.
Un export de commandes ou l’accès aux factures ne doit pas être disponible à n’importe quel visiteur. Le choix du mécanisme d’authentification dépend toutefois de la façon dont les clients utilisent l’API et de la manière dont vous exploitez le service. Vous allez comparer deux stratégies courantes avant de protéger concrètement les routes dans la leçon suivante.
Deux stratégies pour reconnaître un utilisateur
Avec une session côté serveur, l’utilisateur s’authentifie une première fois et le serveur conserve l’état de sa session. Le navigateur reçoit un identifiant de session, généralement dans un cookie, et le renvoie aux requêtes suivantes. L’identifiant ne contient pas à lui seul les droits de l’utilisateur : le serveur s’appuie sur sa propre session pour retrouver l’identité associée.
Avec un jeton d’accès, le client reçoit une valeur qu’il présente aux requêtes suivantes, souvent dans un en-tête HTTP. Le serveur valide ce jeton pour identifier l’appelant et accepter ou rejeter la requête. Selon le format retenu, le serveur peut vérifier une signature ou consulter un service de validation ; un jeton peut aussi être opaque et référencé côté serveur. Dans tous les cas, un jeton est un justificatif d’accès : toute personne qui le récupère peut potentiellement l’utiliser jusqu’à son expiration ou sa révocation.
Comparer les conséquences d’exploitation
Une session donne au service un contrôle direct sur la durée de vie et la révocation : vous pouvez invalider l’état correspondant côté serveur. En contrepartie, cet état doit être accessible à tous les processus qui traitent les requêtes. Si plusieurs instances Express fonctionnent en parallèle, une session conservée uniquement dans la mémoire d’une instance risque de ne pas être retrouvée par une autre. Il faut donc prévoir un stockage partagé adapté à votre déploiement.
Un jeton autonome peut simplifier la vérification par plusieurs services : chacun peut valider le jeton avec les paramètres prévus, sans retrouver une session dans un stockage central. Cette indépendance a une contrepartie : une révocation immédiate est plus difficile si le service ne consulte pas un mécanisme central de révocation. Une durée de validité courte limite cette fenêtre, mais oblige le client à obtenir de nouveaux jetons selon le fonctionnement choisi.
| Critère | Session côté serveur | Jeton d’accès |
|---|---|---|
| Client typique | Application web utilisée dans un navigateur | Application mobile, intégration ou API entre services |
| État à exploiter | Session conservée et partagée côté serveur | Jeton présenté par le client et validé par le service |
| Révocation | Invalider la session côté serveur | Prévoir une expiration courte ou un mécanisme de révocation |
| Point d’attention | Partage du stockage entre instances et protection du cookie | Protection du jeton et maîtrise de sa durée de validité |
Appliquer le choix au service de commandes
Commencez par identifier les consommateurs de l’API : navigateur, application mobile, outil interne ou autre service. Pour chacun, notez comment il conserve et transmet ses justificatifs, s’il faut pouvoir couper rapidement son accès et combien d’instances du service traiteront ses requêtes. Cette liste évite de choisir une stratégie uniquement parce qu’elle est déjà présente dans un exemple ou une bibliothèque.
Dans le projet fil rouge, l’export CSV et les opérations liées aux factures sont des ressources du service, pas des accès anonymes à protéger par un simple bouton d’interface. Si les utilisateurs passent par une interface web, vous pouvez retenir une session et organiser son stockage pour les instances de production. Si des systèmes externes appellent directement l’API, évaluez plutôt un jeton adapté à ces clients ; ne partagez pas automatiquement le même justificatif entre tous les consommateurs.
Consignez votre décision dans la configuration et la documentation d’exploitation : clients concernés, durée de vie retenue, stockage nécessaire et procédure de révocation. Vous avez déjà séparé la configuration par environnement dans la leçon correspondante ; n’inscrivez pas de secret ou de paramètre de production directement dans le code. Le squelette HTML du service reste inchangé : cette décision concerne la manière dont les futures requêtes API seront reconnues.
À retenir
- Une session conserve l’état d’authentification côté serveur ; un jeton est présenté par le client et vérifié par le service.
- Les sessions facilitent la révocation, mais exigent un stockage partagé lorsque plusieurs instances traitent les requêtes.
- Les jetons peuvent convenir à des clients mobiles ou à des intégrations, mais leur durée de vie et leur révocation doivent être prévues.
- Choisissez selon les clients, le déploiement et les besoins d’exploitation ; protégez le justificatif quel que soit le mécanisme.
Dans la leçon suivante, vous appliquerez le mécanisme retenu pour protéger les routes et distinguer l’identité d’un utilisateur de ses permissions.