Authentification JWT vs OAuth
j'ai un nouveau SPA avec un modèle d'authentification apatride utilisant JWT. On me demande souvent de faire référence à OAuth pour les flux d'authentification, comme me demander d'envoyer des 'tokens au porteur' 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 simple 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 aussi le JWT comme jeton XSRF pour empêcher XSRF mais je suis demandé de les garder séparés? Devrais-je le garder séparé? Toute l'aide ici sera apprécié et pourrait conduire à un ensemble de lignes directrices pour la communauté.
7 réponses
TL; DR Si vous avez des scénarios très simples, comme une application client unique, une API unique, alors il pourrait ne pas payer pour go outh 2.0, d'un autre côté, beaucoup de clients différents (basé sur le navigateur, mobile natif, côté serveur, etc), puis le respect des règles OAuth 2.0 pourrait le rendre plus facile à gérer que d'essayer de rouler votre propre système.
comme indiqué dans une autre réponse, JWT ( apprendre JSON Web Tokens ) est juste un format de jeton, il définit un mécanisme compact et autonome pour la transmission de données entre les parties d'une manière qui peut être vérifiée et de confiance parce qu'il est signé numériquement. De plus, les règles d'encodage D'un JWT rendent ces tokens 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 l'authentification apatride mécanismes (aka Regarde maman, pas de séances de! ). Dans cette voie, et la seule chose qu'un parti 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é un jeton porteur.
en pratique, ce que vous faites peut déjà être classé comme basé sur des jetons au porteur. Cependant, ne considérez pas que vous n'utilisez pas des jetons au porteur comme spécifié par les spécifications connexes de L'OAuth 2.0 (voir RFC 6750 ). Cela impliquerait de se fier à 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 prévenir CSRF sans connaître les détails exacts, il est difficile de vérifier la validité de cette pratique, mais pour être honnête, il ne semble pas correct et/ou utile. L'article suivant ( Cookies vs Tokens: le Guide définitif ) peut être une lecture utile sur ce sujet, en particulier le XSS and XSRF Protection section.
un dernier conseil, Même si vous n'avez pas besoin d'aller au complet OAuth 2.0, Je recommande fortement de passer votre token d'accès dans l'en-tête Authorization au lieu d'aller avec des en-têtes personnalisés . Si ce 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.
Les en-têtes D'autorisationsont reconnus et traités spécialement par les serveurs et mandataires HTTP. Ainsi, l'utilisation de tels en-têtes pour envoyer des jetons d'accès aux serveurs de ressources réduit la probabilité de fuite ou de stockage non intentionnel des requêtes authentifiées en général, et en particulier des en-têtes D'autorisation.
(source: RFC 6819, section 5.4.1 )
OAuth 2.0 définit un protocole, i.e. spécifie comment les tokens sont transférés, JWT définit un format de token.
OAuth 2.0 et "authentification JWT" ont une apparence similaire lorsqu'il s'agit de l'étape (2) où le Client présente le token au serveur de ressources: le token est passé dans un en-tête.
mais "authentification JWT" n'est pas une norme et ne spécifie pas comment le Client obtient le token en premier lieu (au 1er étage). C'est de là que vient la complexité perçue de OAuth: elle définit également les différentes façons dont le Client peut obtenir un jeton d'accès à partir de quelque chose qui s'appelle un serveur D'autorisation.
donc la vraie différence est que JWT est juste un format de jeton, OAuth 2.0 est un protocole (que may utilise un JWT comme format de jeton).
tout d'abord, nous devons différencier JWT et OAuth. Fondamentalement, JWT est un format de token. OAuth est un framework d'authentification qui peut utiliser JWT comme jeton. OAuth utilise le stockage côté serveur et le stockage côté client. Si vous voulez faire une déconnexion réelle, vous devez utiliser OAuth2. L'authentification avec JWT token ne peut pas se déconnecter en fait. Parce que vous n'avez pas de serveur D'authentification qui garde la trace des tokens. Si vous souhaitez fournir une API à des clients tiers, vous devez également utiliser OAuth2. OAuth2 est très flexible. La mise en œuvre de la JWT est très facile et ne prend pas beaucoup de temps. Si votre application a besoin de ce type de flexibilité, vous devriez choisir OAuth2. Mais si vous n'avez pas besoin de ce scénario d'utilisation, mettre en œuvre OAuth2 est une perte de temps.
Le tokenXSRF est toujours envoyé au client dans chaque en-tête de réponse. Peu importe qu'un jeton CSRF soit envoyé dans un JWT ou non, parce que le jeton CSRF est sécurisé avec lui-même. Par conséquent, l'envoi D'un jeton CSRF dans JWT est inutile.
on dirait que tous ceux qui ont répondu ici ont manqué le point discutable de OAUTH
De Wikipedia
OAuth est une norme ouverte pour la délégation d'accès, couramment utilisé comme un moyen pour les utilisateurs de l'Internet d'accorder des sites web ou des applications d'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 tierces ou des sites web.
le point clé ici est access delegation . Pourquoi quelqu'un créerait OAUTH quand il y a une authentification basée sur id/pwd, soutenue par un auteur multifactoriel comme OTPs et peut être sécurisé par des JWTs qui sont utilisés pour sécuriser l'accès aux chemins (comme les scopes dans OAUTH) et régler l'expiration de l'accès
il n'y a pas de raison d'utiliser OAUTH si les consommateurs accèdent à leurs ressources(vos points d'arrivée) uniquement par l'intermédiaire de leurs sites web(ou applications) de confiance qui sont à nouveau hébergés sur vos points d'arrivée
vous pouvez accéder à l'authentification seulement si vous êtes un OAUTH provider dans les cas où les propriétaires de ressources (utilisateurs) veulent accéder à leurs ressources(vos) (end-points) via un client tiers(app externe). et il est exactement créé pour le même but bien que vous pouvez en abuser en général
autre note importante:
Vous utilisez librement le mot authentication pour JWT et OAUTH mais ni l'un ni l'autre ne fournit le mécanisme d'authentification. Oui, l'un est un mécanisme symbolique et l'autre est un protocole, mais une fois authentifiés, ils ne sont utilisés que pour l'autorisation (Gestion des accès). Vous devez sauvegarder OAUTH soit avec une authentification de type OPENID soit avec vos propres justificatifs d'identité de client
JWT (JSON Web Tokens) - c'est juste un format de token. JWT les jetons sont encodées JSON structures de données contient des informations sur l'émetteur, l'objet (la demande), heure d'expiration, etc. Il est signé pour preuve d'altération et authenticité et il peut être crypté pour protéger les informations token en utilisant une approche symétrique ou asymétrique. JWT est plus simple que SAML 1.1 / 2.0 et pris en charge par tous les appareils et il est plus puissant que SWT(Simple Web Token).
OAuth2 - OAuth2 résoudre un problème que l'utilisateur veut accéder aux données en utilisant des logiciels clients comme les applications Web de navigation, natives applications mobiles ou applications de bureau. OAuth2 est juste pour l'autorisation, le logiciel client peut être autorisé à accéder aux ressources au nom de l'utilisateur final en utilisant access token.
OpenID Connect - OpenID Connect construit sur OAuth2 et ajoute authentification. Ajouter une contrainte à OAuth2 like UserInfo point de Terminaison, l'ID de Jeton, la découverte et l'enregistrement dynamique d'OpenID Connect fournisseurs et la gestion de session. JWT est le format obligatoire pour le token.
protection CSRF - vous n'avez pas besoin de mettre en œuvre la protection CSRF si vous ne stockez pas de token dans le cookie du navigateur.
vous pouvez lire plus de détails ici http://proficientblog.com/microservices-security /
JWT est un protocole d'authentification où nous permettons le transfert de revendications encodées (token) entre deux parties (client et serveur) et le token est émis après l'identification du client. avec chaque demande ultérieure nous envoyons le token
attendu que Oauth2 est un framework d'authentification, où il a des procédures générales et des configurations définies par framework. JWT peut être utilisé comme mécanisme à L'intérieur de Oauth2
vous pouvez lire plus sur ce ici
Jwt est un ensemble d'instructions strictes pour la délivrance et la validation des jetons d'accès signés. Les tokens contiennent des revendications qui sont utilisées par une application pour limiter l'accès à un utilisateur
OAuth2 n'est pas un protocole, mais un cadre d'autorisation délégué. pensez à des lignes directrices très détaillées, pour permettre aux utilisateurs et aux applications d'autoriser des permissions spécifiques à d'autres applications dans des environnements privés et publics. OpenID Connect qui se trouve sur OAUTH2 vous donne L'authentification et L'autorisation.il détaille comment de multiples rôles différents, les utilisateurs dans votre système, les applications côté serveur comme une API, et les clients tels que les sites web ou applications mobiles natives, peuvent authentifier avec chaque othe
Note oauth2 peut travailler avec jwt , une mise en œuvre souple, extandable à différentes applications