Quelles sont les principales différences entre l'authentification JWT et OAuth ?

Question

J'ai un nouveau 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, par exemple en me demandant d'envoyer des "Bearer tokens" pour chaque requête au lieu d'un simple en-tête de jeton, mais je pense qu'OAuth est beaucoup plus complexe qu'une simple authentification basée sur JWT. Quelles sont les principales différences, dois-je faire en sorte que l'authentification JWT se comporte comme OAuth ?

J'utilise également le JWT comme XSRF-TOKEN pour éviter les XSRF, mais on me demande de les garder séparés ? Devrais-je les séparer ? Toute aide sera appréciée et pourrait conduire à l'élaboration de directives pour la communauté.

Answer 1

TL;DR Si vous avez des scénarios très simples, comme une application client unique, une API unique, il n'est peut-être pas rentable d'adopter OAuth 2.0. En revanche, si vous avez beaucoup de clients différents (navigateur, mobile natif, côté serveur, etc.), respecter les règles d'OAuth 2.0 peut rendre la situation plus facile à gérer que d'essayer de mettre en place votre propre système.

---

Comme indiqué dans une autre réponse, JWT ( Apprendre les jetons Web JSON ) n'est qu'un format de jeton, il définit un mécanisme compact et autonome pour transmettre des données entre des parties d'une manière qui peut être vérifiée et fiable car elle est signée numériquement. En outre, les règles d'encodage d'un JWT rendent ces jetons très faciles à utiliser dans le contexte de HTTP.

Étant donné qu'ils sont autonomes (le jeton réel contient des informations sur un sujet donné), ils constituent également un bon choix pour la mise en œuvre de mécanismes d'authentification apatrides (alias Regarde maman, pas de séances ! ). Lorsque l'on suit cette voie et que 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, le jeton en question peut être appelé jeton porteur.

En pratique, ce que vous faites peut déjà être classé comme basé sur des jetons au porteur. Cependant, tenez compte du fait que vous n'utilisez pas de jetons de porteur comme spécifié par les spécifications liées à OAuth 2.0 (cf. RFC 6750 ). Cela impliquerait, en s'appuyant sur le Authorization et en utilisant l'en-tête HTTP Bearer schéma d'authentification.

En ce qui concerne l'utilisation de JWT pour empêcher CSRF, sans connaître les détails exacts, il est difficile de vérifier la validité de cette pratique, mais pour être honnête, elle ne semble pas correcte et/ou utile. L'article suivant ( Cookies et jetons : Le guide définitif ) peut être une lecture utile sur ce sujet, en particulier l'article intitulé Protection contre les XSS et XSRF section.

Un dernier conseil, même si vous n'avez pas besoin de passer à la version complète d'OAuth 2.0. Il est fortement recommandé de transmettre votre jeton d'accès dans l'interface de l'utilisateur. Authorization au lieu d'utiliser des en-têtes personnalisés . S'il s'agit vraiment de 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.

Les en-têtes d'autorisation sont reconnus et traités spécialement par les proxies et les serveurs HTTP. Ainsi, l'utilisation de ces en-têtes pour envoyer des jetons d'accès aux serveurs de ressources réduit la probabilité de fuite ou de stockage involontaire des demandes authentifiées en général, et en particulier des en-têtes d'autorisation.

(source : RFC 6819, section 5.4.1 )

Answer 2

OAuth 2.0 définit un protocole, c'est-à-dire précise comment les jetons sont transférés, JWT définit un format de jeton.

OAuth 2.0 et "l'authentification JWT" ont une apparence similaire lorsqu'il s'agit de la (2ème) étape où le client présente le jeton au serveur de ressources : le jeton est transmis dans un en-tête.

Mais "l'authentification JWT" n'est pas une norme et ne spécifie pas comment le client obtient le jeton en premier lieu (la première étape). C'est de là que vient la complexité perçue d'OAuth : il définit également différentes manières dont le client peut obtenir un jeton d'accès à partir de quelque chose qui est appelé un serveur d'autorisation.

La vraie différence est donc que JWT est juste un format de jeton, OAuth 2.0 est un protocole (qui mai utiliser un JWT comme format de jeton).

Answer 3

Tout d'abord, nous devons différencier JWT et OAuth. Fondamentalement, JWT est un format de jeton. OAuth est un protocole d'autorisation qui peut utiliser JWT comme jeton. OAuth utilise le stockage côté serveur et côté client. Si vous voulez faire une vraie déconnexion, vous devez utiliser OAuth2. L'authentification avec un jeton JWT ne permet pas de se déconnecter réellement. Parce que vous n'avez pas de serveur d'authentification qui garde la trace des jetons. Si vous souhaitez fournir une API à des clients tiers, vous devez également utiliser OAuth2. OAuth2 est très flexible. La mise en œuvre de JWT est très facile et ne prend pas beaucoup de temps. Si votre application a besoin de ce type de flexibilité, vous devriez opter pour OAuth2. Mais si vous n'avez pas besoin de ce scénario d'utilisation, la mise en œuvre d'OAuth2 est une perte de temps.

Le jeton XSRF est toujours envoyé au client dans chaque en-tête de réponse. Il importe peu qu'un jeton CSRF soit envoyé dans un jeton JWT ou non, car le jeton CSRF est sécurisé par lui-même. Par conséquent, l'envoi d'un jeton CSRF dans JWT est inutile.

Answer 4

JWT (Jetons Web JSON) - Il s'agit simplement d'un format de jeton. Les jetons JWT sont des structures de données codées en JSON qui contiennent des informations sur l'émetteur, le sujet (revendications), le délai d'expiration, etc. Ils sont signés pour garantir l'inviolabilité et l'authenticité et peuvent être chiffrés pour protéger les informations du jeton en utilisant une approche symétrique ou asymétrique. JWT est plus simple que SAML 1.1/2.0 et est supporté par tous les appareils. Il est plus puissant que SWT (Simple Web Token).

OAuth2 - OAuth2 résout le problème de l'utilisateur qui veut accéder aux données en utilisant un logiciel client comme les applications Web basées sur le navigateur, les applications mobiles natives ou les applications de bureau. OAuth2 ne sert qu'à l'autorisation, le logiciel client peut être autorisé à accéder aux ressources au nom de l'utilisateur final en utilisant un jeton d'accès.

OpenID Connect - OpenID Connect s'appuie sur OAuth2 et ajoute l'authentification. OpenID Connect ajoute certaines contraintes à OAuth2 comme le UserInfo Endpoint, le jeton d'identification, la découverte et l'enregistrement dynamique des fournisseurs OpenID Connect et la gestion des sessions. JWT est le format obligatoire pour le jeton.

Protection contre le CSRF - Vous n'avez pas besoin de mettre en œuvre la protection CSRF si vous ne stockez pas de jeton dans le cookie du navigateur.

Answer 5

On dirait que tous ceux qui ont répondu ici ont manqué le point essentiel de OAUTH.

De Wikipedia

OAuth est une norme ouverte de délégation d'accès, couramment utilisée comme un moyen pour les internautes d'accorder à des sites Web ou à des applications l'accès à leurs informations sur d'autres sites Web, mais sans leur donner les mots de passe[1]. Ce mécanisme est utilisé par des entreprises telles que Google, Facebook, Microsoft et Twitter pour permettre aux utilisateurs de partager des informations sur leurs comptes avec des applications ou des sites Web tiers.

Le point clé ici est access delegation . Pourquoi créer OAUTH alors qu'il existe une authentification basée sur l'identifiant et le mot de passe, soutenue par une authentification multifactorielle comme les OTP et qui peut être sécurisée par des JWT qui sont utilisés pour sécuriser l'accès aux chemins (comme les scopes dans OAUTH) et définir l'expiration de l'accès.

Il est inutile d'utiliser OAUTH si les consommateurs n'accèdent à leurs ressources (vos points d'extrémité) que par l'intermédiaire de leurs sites web (ou applications) de confiance qui sont à nouveau hébergés sur vos points d'extrémité.

Vous pouvez opter pour l'authentification OAUTH uniquement si vous êtes un OAUTH provider dans les cas où les propriétaires de ressources (utilisateurs) veulent accéder à leurs ressources (points finaux) via un client tiers (application externe). Et il est exactement créé dans le même but, bien que vous puissiez en abuser en général.

Une autre note importante :
Vous utilisez librement le mot authentication pour JWT et OAUTH mais aucun ne fournit le mécanisme d'authentification. Oui, l'un est un mécanisme de jeton et l'autre un protocole, mais une fois authentifiés, ils ne sont utilisés que pour l'autorisation (gestion des accès). Vous devez soutenir OAUTH soit avec une authentification de type OPENID, soit avec les informations d'identification de votre propre client.