human
J'ai une nouvelle application SPA avec un modèle d'authentification sans état utilisant JWT. On me demande souvent de me référer à OAuth pour les flux d'authentification, comme me demander d'envoyer des 'jetons porteurs' pour chaque requête au lieu d'un simple en-tête de jeton, mais je pense que OAuth est beaucoup plus complexe qu'une simple authentification basée sur JWT. Quelles sont les principales différences, devrais-je faire en sorte que l'authentification JWT se comporte comme OAuth ?
J'utilise également le JWT comme mon XSRF-TOKEN pour prévenir les attaques XSRF, mais on me demande de les garder séparés ? Devrais-je les garder séparés ? Toute aide ici sera appréciée et pourrait conduire à un ensemble de lignes directrices pour la communauté
gpt
TL;DR Si vous avez des scénarios très simples, comme une seule application cliente, une seule API, il se peut que cela ne vaille pas la peine d'utiliser OAuth 2.0. En revanche, s'il y a de nombreux clients différents (basés sur un navigateur, mobiles natifs, côté serveur, etc.), respecter les règles d'OAuth 2.0 pourrait rendre les choses plus gérables que d'essayer de créer votre propre système.

## Réponse détaillée

JWT (apprenez les JSON Web Tokens) est simplement un format de jeton. Il définit un mécanisme compact et autonome pour transmettre des données entre les parties de manière à pouvoir être vérifié et fiable car il est signé numériquement. De plus, les règles d'encodage d'un JWT rendent également ces jetons très faciles à utiliser dans le contexte de HTTP.

Étant autonomes (le jeton réel contient des informations sur un sujet donné), ils sont également un bon choix pour mettre en œuvre des mécanismes d'authentification sans état (aka Look mum, no sessions !). Lorsque vous empruntez cette voie, la seule chose qu'une partie doit présenter pour obtenir l'accès à une ressource protégée est le jeton lui-même, et le jeton en question peut être appelé un jeton porteur.

En pratique, ce que vous faites peut déjà être classé comme basé sur un jeton porteur. Cependant, veuillez noter que vous n'utilisez pas de jetons porteurs tels que spécifiés par les spécifications liées à OAuth 2.0 (voir RFC 6750). Cela impliquerait de s'appuyer sur l'en-tête HTTP Authorization et d'utiliser le schéma d'authentification Bearer.

En ce qui concerne l'utilisation du JWT pour prévenir les attaques CSRF : sans connaître les détails exacts, il est difficile de déterminer la validité de cette pratique. Pour être honnête, cela ne semble pas correct et/ou utile. L'article suivant (Cookies vs Tokens: The Definitive Guide) peut être une lecture utile sur ce sujet, en particulier la section sur la protection XSS et XSRF.

Un dernier conseil. Même si vous n'avez pas besoin d'adopter complètement OAuth 2.0, je vous recommande vivement de transmettre votre jeton d'accès dans l'en-tête Authorization au lieu d'utiliser des en-têtes personnalisés. S'ils sont vraiment des jetons porteurs, suivez les règles de la RFC 6750. Sinon, vous pouvez toujours créer un schéma d'authentification personnalisé et utiliser cet en-tête.