Quelles sont les principales différences entre l'authentification JWT et OAuth?
J'ai un nouveau SPA avec un modèle d'authentification sans état utilisant JWT. On me demande souvent de référencer OAuth pour des flux d'authentification, comme de m'envoyer des "jetons de support" 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 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 XSRF-TOKEN pour prévenir les 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 directives pour la communauté.
TL; DR Si vous avez des scénarios très simples, comme une application cliente unique, une API unique, il pourrait ne pas être rentable de passer à OAuth 2.0, par contre de nombreux clients différents (basés sur le navigateur). , Natif mobile, côté serveur, etc.) s'en tenir aux règles OAuth 2.0 pourrait le rendre plus facile à gérer que d'essayer de lancer votre propre système.
Comme indiqué dans une autre réponse, JWT ( Learn JSON Web Tokens ) est simplement un format de jeton. Il définit un mécanisme compact et autonome pour la transmission de données entre les parties de manière vérifiable et fiable, car numérique. signé. De plus, les règles de codage d'un JWT rendent ces jetons très faciles à utiliser dans le contexte de HTTP.
Étant autonomes (le jeton contient des informations sur un sujet donné), ils constituent également un bon choix pour la mise en œuvre de mécanismes d'authentification sans état (aka Look mum, no sessions!). Lorsque vous vous rendez sur cette route et que la seule chose qu'une partie doit présenter pour avoir accès à une ressource protégée est le jeton lui-même, le jeton en question peut être appelé un jeton porteur.
En pratique, ce que vous faites peut déjà être classé comme basé sur les jetons porteurs. Cependant, considérez que vous n'utilisez pas de jetons porteurs comme spécifié dans les spécifications relatives à 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 de la JWT pour empêcher CSRF sans connaître les détails exacts, il est difficile de déterminer la validité de cette pratique, mais pour être honnête, cela ne semble pas correct et/ou valable. L'article suivant ( Cookies vs Tokens: The Definitive Guide ) peut être une lecture utile sur ce sujet, en particulier la section Protection XSS et XSRF.
Un dernier conseil, même si vous n’avez pas besoin d’utiliser complètement OAuth 2.0, je recommande fortement de transmettre votre jeton d’accès à l’en-tête Authorization au lieu d’utiliser des en-têtes personnalisés. S'ils sont vraiment porteurs, les règles de la RFC 6750 sont respectées. Sinon, vous pouvez toujours créer un schéma d'authentification personnalisé tout en utilisant cet en-tête.
Les en-têtes d'autorisation sont reconnus et spécialement traités par les serveurs proxy et HTTP. Ainsi, l'utilisation de tels en-têtes pour envoyer des jetons d'accès aux serveurs de ressources réduit le risque de fuite ou de stockage non intentionnel de demandes authentifiées en général, et notamment d'en-têtes d'autorisation.
(source: RFC 6819, section 5.4.1 )
OAuth 2.0 définit un protocole, c'est-à-dire spécifie comment les jetons sont transférés, JWT définit un format de jeton.
OAuth 2.0 et "authentification JWT" ont une apparence similaire en ce qui concerne l'étape (2ème) 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 un standard et ne spécifie pas comment le client obtient le jeton en premier lieu (la 1ère étape). C’est d’où vient la complexité perçue d’OAuth: il définit également diverses manières par lesquelles le client peut obtenir un jeton d’accès à partir de quelque chose appelé serveur d’autorisation.
La vraie différence est donc que JWT est juste un format de jeton, OAuth 2.0 est un protocole (qui peut utilise un JWT comme format de jeton).
Tout d'abord, nous devons différencier JWT et OAuth. Fondamentalement, JWT est un format de jeton. OAuth est un protocole d'autorisation pouvant utiliser JWT en tant que jeton. OAuth utilise un stockage côté serveur et côté client. Si vous voulez réellement vous déconnecter, vous devez utiliser OAuth2. L'authentification avec le jeton JWT ne peut pas se déconnecter réellement. Parce que vous n'avez pas de serveur d'authentification qui garde une 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 rapide. Si votre application a besoin de ce type de flexibilité, optez pour OAuth2. Mais si vous n'avez pas besoin de ce scénario d'utilisation, implémenter OAuth2 est une perte de temps.
Le jeton XSRF est toujours envoyé au client dans chaque en-tête de réponse. Peu importe qu'un jeton CSRF soit envoyé dans un jeton JWT ou non, car le jeton CSRF est sécurisé avec lui-même. Par conséquent, l'envoi d'un jeton CSRF dans JWT n'est pas nécessaire.
JWT (jetons Web JSON) - Il s'agit simplement d'un format de jeton. Les jetons JWT sont des structures de données codées JSON contenant des informations sur l'émetteur, le sujet (revendications), le délai d'expiration, etc. Il est signé pour la sécurité et l'authenticité. JWT est plus simple que SAML 1.1/2.0 et est supporté par tous les périphériques. Il est plus puissant que SWT (Simple Web Token).
OAuth2 - OAuth2 résout le problème selon lequel l'utilisateur souhaite accéder aux données à l'aide d'un logiciel client, tel que des applications Web basées sur la navigation, des applications mobiles natives ou des applications de bureau. OAuth2 sert uniquement à l'autorisation. Le logiciel client peut être autorisé à accéder aux ressources pour le compte de l'utilisateur final à l'aide d'un jeton d'accès.
OpenID Connect - OpenID Connect repose sur OAuth2 et ajoute une authentification. OpenID Connect ajoute des contraintes à OAuth2 telles que UserInfo Endpoint, ID Token, la découverte et l'enregistrement dynamique des fournisseurs OpenID Connect et la gestion de session. JWT est le format obligatoire pour le jeton.
Protection CSRF - Vous n'avez pas besoin d'implémenter la protection CSRF si vous ne stockez pas de jeton dans le cookie du navigateur.
Vous pouvez lire plus de détails ici http://proficientblog.com/microservices-security/
Il semble que toutes les personnes qui ont répondu ici ont raté le but de OAUTH
De Wikipedia
OAuth est un standard ouvert pour la délégation d'accès, utilisé couramment pour permettre aux utilisateurs Internet d'octroyer aux sites Web ou aux applications l'accès à leurs informations sur d'autres sites Web, sans toutefois leur fournir de mot de passe. [1] Ce mécanisme est utilisé par des sociétés 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 quelqu'un créerait-il OAUTH lorsqu'il existe une authentification basée sur id/pwd, adossée à une authentification multifactorisée comme les OTP et peut en outre être sécurisée par des JWT utilisés pour sécuriser l'accès aux chemins (comme les portées dans OAUTH) et définir l'expiration du accès
Il est inutile d'utiliser OAUTH si les consommateurs accèdent à leurs ressources (vos points finaux) uniquement via leurs sites Web (ou applications) de confiance, qui sont à nouveau hébergés sur vos points finaux.
Vous ne pouvez utiliser que l'authentification OAUTH si vous êtes un OAUTH provider dans les cas où les propriétaires de ressources (utilisateurs) souhaitent accéder à leurs (vos) ressources (points de terminaison) via un client tiers (application externe). Et il est créé exactement dans le même but, bien que vous puissiez en abuser en général.
Une autre note importante:
Vous utilisez librement Word authentication pour JWT et OAUTH mais vous ne fournissez pas 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 de l'accès). Vous devez sauvegarder OAUTH avec une authentification de type OPENID ou vos propres informations d'identification client
JWT est un protocole d'authentification dans lequel nous autorisons le transfert de revendications codées (jetons) entre deux parties (client et serveur) et le jeton est émis lors de l'identification d'un client. A chaque demande ultérieure, nous envoyons le jeton.
Considérant que OAuth2 est un cadre d'autorisation, où il a des procédures générales et des configurations définies par le cadre. JWT peut être utilisé comme mécanisme dans OAuth2.
Vous pouvez en lire plus ici
trouver les principales différences entre JWT et OAuth
OAuth 2.0 définit un protocole et JWT définit un format de jeton.
OAuth peut utiliser JWT comme format de jeton ou comme jeton d'accès, qui est un jeton porteur.
OpenID Connect utilise principalement JWT comme format de jeton.
Jwt est un ensemble d'instructions strict pour l'émission et la validation de jetons d'accès signés. Les jetons contiennent des revendications qui sont utilisées par une application pour limiter l'accès à un utilisateur.
D'autre part, OAuth2 n'est pas un protocole, c'est un cadre d'autorisation délégué. pense que des instructions très détaillées permettent aux utilisateurs et aux applications d’autoriser des autorisations spécifiques à d’autres applications dans des environnements privés et publics. OpenID Connect, qui se trouve au-dessus d’OAUTH2, vous fournit Authentication et Authorization.it explique comment de multiples rôles, utilisateurs de votre système, applications côté serveur (telles qu’une API) et clients, tels que des sites Web ou des applications mobiles natives, peuvent s’authentifier de manière différente.
Remarque oauth2 peut fonctionner avec jwt, une implémentation flexible, extandable vers différentes applications.