Introduction
L’authentification basée sur des jetons est omniprésente sur le Web de nos jours. La plupart des entreprises Web utilisant une API, les jetons sont le meilleur moyen de gérer l’authentification pour plusieurs utilisateurs.
Certains facteurs sont très importants lors du choix de l’authentification par jeton pour votre application. Les principales raisons des jetons sont:
- Serveurs sans état et évolutifs
- Prêt pour les applications mobiles
- Passer l’authentification à d’autres applications
- Sécurité supplémentaire
Qui utilise l’authentification basée sur des jetons ?
Toute API ou application Web majeure que vous avez rencontrée a très probablement utilisé des jetons. Des applications comme Facebook, Twitter, Google+, GitHub et bien d’autres utilisent des jetons.
Regardons exactement comment cela fonctionne.
Pourquoi les Jetons sont venus
Avant de pouvoir voir comment fonctionne l’authentification basée sur les jetons et ses avantages, nous devons examiner la façon dont l’authentification a été effectuée dans le passé.
Authentification basée sur le serveur (La méthode traditionnelle)
Étant donné que le protocole HTTP est sans état, cela signifie que si nous authentifions un utilisateur avec un nom d’utilisateur et un mot de passe, notre application ne saura pas qui nous sommes lors de la prochaine demande. Nous devrions nous authentifier à nouveau.
La façon traditionnelle de faire en sorte que nos applications se souviennent de qui nous sommes consiste à stocker les informations de connexion de l’utilisateur sur le serveur. Cela peut être fait de différentes manières sur la session, généralement en mémoire ou stockée sur le disque.
Avec le web, les applications et l’essor de l’application mobile, cette méthode d’authentification a montré des problèmes, notamment en termes d’évolutivité.
Les problèmes avec l’authentification basée sur le serveur
Quelques problèmes majeurs sont apparus avec cette méthode d’authentification.
- Séances: Chaque fois qu’un utilisateur est authentifié, le serveur devra créer un enregistrement quelque part sur notre serveur. Cela se fait généralement en mémoire et lorsque de nombreux utilisateurs s’authentifient, la surcharge sur votre serveur augmente.
- Évolutivité : Comme les sessions sont stockées en mémoire, cela pose des problèmes d’évolutivité. Alors que nos fournisseurs de cloud commencent à répliquer des serveurs pour gérer la charge des applications, le fait d’avoir des informations vitales dans la mémoire de session limitera notre capacité à évoluer.
- CORS: Comme nous voulons étendre notre application pour permettre à nos données d’être utilisées sur plusieurs appareils mobiles, nous devons nous soucier du partage de ressources inter-origines (CORS). Lorsque vous utilisez des appels AJAX pour récupérer des ressources d’un autre domaine (mobile vers notre serveur API), nous pourrions rencontrer des problèmes avec les requêtes interdites.
- CSRF: Nous disposerons également d’une protection contre la falsification de demandes intersite (CSRF). Les utilisateurs sont sensibles aux attaques CSRF car ils peuvent déjà être authentifiés par exemple avec un site bancaire et cela pourrait être utilisé lors de la visite d’autres sites.
Avec ces problèmes, l’évolutivité étant le principal, il était logique d’essayer une approche différente.
Fonctionnement Basé sur des jetons
L’authentification basée sur des jetons est sans état. Nous ne stockons aucune information sur notre utilisateur sur le serveur ou dans une session.
Ce concept résout à lui seul de nombreux problèmes liés au stockage d’informations sur le serveur.
Aucune information de session ne signifie que votre application peut évoluer et ajouter d’autres machines si nécessaire sans se soucier de l’endroit où un utilisateur est connecté.
Bien que cette implémentation puisse varier, l’essentiel est le suivant:
- L’utilisateur demande l’accès avec le nom d’utilisateur / mot de passe
- L’application valide les informations d’identification
- L’application fournit un jeton signé au client
- Le client stocke ce jeton et l’envoie avec chaque demande
- Le serveur vérifie le jeton et répond avec les données
Chaque demande nécessite le jeton. Ce jeton doit être envoyé dans l’en-tête HTTP afin que nous conservions l’idée de requêtes HTTP sans état. Nous devrons également configurer notre serveur pour qu’il accepte les demandes de tous les domaines en utilisant Access-Control-Allow-Origin: *. Ce qui est intéressant à propos de la désignation * dans l’en-tête ACAO, c’est qu’elle n’autorise pas les demandes à fournir des informations d’identification telles que l’authentification HTTP, les certificats SSL côté client ou les cookies.
Une fois que nous nous sommes authentifiés avec nos informations et que nous avons notre jeton, nous pouvons faire beaucoup de choses avec ce jeton.
Nous pourrions même créer un jeton basé sur une autorisation et le transmettre à une application tierce (disons une nouvelle application mobile que nous voulons utiliser), et ils pourront avoir accès à nos données – mais uniquement aux informations que nous avons autorisées avec ce jeton spécifique.
Les avantages des jetons
Sans état et évolutifs
Les jetons sont stockés côté client. Complètement apatride et prêt à être mis à l’échelle. Nos équilibreurs de charge sont capables de transmettre un utilisateur à l’un de nos serveurs car il n’y a aucune information d’état ou de session nulle part.
Si nous conservions des informations de session sur un utilisateur connecté, cela nous obligerait à continuer à envoyer cet utilisateur au même serveur sur lequel il s’est connecté (appelé affinité de session).
Cela pose des problèmes car certains utilisateurs seraient forcés d’accéder au même serveur et cela pourrait entraîner un trafic important.
Ne vous inquiétez pas cependant! Ces problèmes ont disparu avec les jetons car le jeton lui-même contient les données de cet utilisateur.
Sécurité
Le jeton, pas un cookie, est envoyé à chaque demande et comme aucun cookie n’est envoyé, cela aide à prévenir les attaques CSRF. Même si votre implémentation spécifique stocke le jeton dans un cookie côté client, le cookie n’est qu’un mécanisme de stockage au lieu d’un mécanisme d’authentification. Il n’y a pas d’informations basées sur la session à manipuler puisque nous n’avons pas de session!
Le jeton expire également après un laps de temps défini, de sorte qu’un utilisateur devra se connecter à nouveau. Cela nous aide à rester en sécurité. Il existe également le concept de révocation de jetons qui nous permet d’invalider un jeton spécifique et même un groupe de jetons basés sur la même autorisation.
Extensibilité (Ami d’un Ami et Autorisations)
Les jetons nous permettront de créer des applications qui partagent des autorisations avec un autre. Par exemple, nous avons lié des comptes sociaux aléatoires à nos principaux comptes comme Facebook ou Twitter.
Lorsque nous nous connectons à Twitter via un service (disons Buffer), nous autorisons Buffer à publier sur notre flux Twitter.
En utilisant des jetons, c’est ainsi que nous fournissons des autorisations sélectives aux applications tierces. Nous pourrions même créer notre propre API et distribuer des jetons d’autorisation spéciaux si nos utilisateurs voulaient donner accès à leurs données à une autre application.
Plusieurs plates-formes et domaines
Nous avons parlé un peu de CORS plus tôt. Lorsque notre application et notre service se développeront, nous devrons fournir un accès à toutes sortes d’appareils et d’applications (car notre application deviendra très certainement populaire!).
Notre API ne servant que des données, nous pouvons également faire le choix de conception de servir des actifs à partir d’un CDN. Cela élimine les problèmes que CORS soulève après avoir défini une configuration d’en-tête rapide pour notre application.
Access-Control-Allow-Origin: *Nos données et ressources sont désormais disponibles pour les requêtes de n’importe quel domaine tant qu’un utilisateur dispose d’un jeton valide.
Basé sur des normes
Lors de la création du jeton, vous avez quelques options. Nous nous pencherons davantage sur ce sujet lorsque nous sécuriserons une API dans un article de suivi, mais la norme à utiliser serait les jetons Web JSON.
Ce graphique de débogueur et de bibliothèque pratique montre la prise en charge des jetons Web JSON. Vous pouvez voir qu’il a une grande quantité de support dans une variété de langues. Cela signifie que vous pouvez réellement désactiver votre mécanisme d’authentification si vous choisissez de le faire à l’avenir!
Conclusion
Ce n’était qu’un aperçu du comment et du pourquoi de l’authentification par jeton. Comme c’est toujours le cas dans le monde de la sécurité, il y a beaucoup plus à chaque sujet et cela varie selon les cas d’utilisation. Nous avons même abordé certains sujets sur l’évolutivité qui méritent également sa propre conversation.
Il s’agissait d’un aperçu rapide de haut niveau, n’hésitez donc pas à signaler tout ce qui a été manqué ou toute question que vous avez à ce sujet.
Dans notre prochain article, nous examinerons l’anatomie des jetons Web JSON.
Remarque: Ajout d’informations d’en-tête ACAO et de clarifications CSRF (merci à Emily Stark pour les informations de l’article)