J'ai un nouveau SPA avec un modèle d'authentification sans état utilisant JWT. On me demande souvent de faire référence à OAuth pour les flux d'authentification, par exemple en me demandant d'envoyer des "Bearer tokens" pour chaque demande 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 séparer. Dois-je les séparer ? Toute aide sera appréciée et pourrait déboucher sur un ensemble de directives pour la communauté.
TL;DR Si vous avez des scénarios très simples, comme une application client unique, une API unique, alors il n'est peut-être pas rentable d'opter pour OAuth 2.0. En revanche, si vous avez beaucoup de clients différents (navigateur, mobile natif, côté serveur, etc.), le fait de s'en tenir aux règles d'OAuth 2.0 peut être plus facile à gérer que d'essayer de mettre en place votre propre système.
Comme indiqué dans une autre réponse, JWT ([Learn JSON Web Tokens][1]) 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.
Comme ils sont autonomes (le jeton proprement dit 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 (alias Look mum, no sessions!). Lorsque cette voie est choisie 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 reposant sur des jetons au porteur. Toutefois, il faut tenir compte du fait que vous n'utilisez pas les jetons de porteur tels que spécifiés par les spécifications liées à OAuth 2.0 (voir [RFC 6750][2]). Cela implique 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 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 vs Tokens : The Definitive Guide][3]) peut être une lecture utile sur ce sujet, en particulier la section Protection contre les XSS et XSRF.
Un dernier conseil, même si vous n'avez pas besoin d'aller jusqu'au bout de OAuth 2.0, je recommande fortement de passer votre jeton d'accès dans l'en-tête Authorization
au lieu d'utiliser des en-têtes personnalisés. S'il s'agit vraiment de jetons de porteur, 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 l'envoi de 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 des en-têtes d'autorisation en particulier.
(source : [RFC 6819, section 5.4.1][4])
[1] : https://auth0.com/learn/json-web-tokens/ [2] : https://tools.ietf.org/html/rfc6750 [3] : https://dzone.com/articles/cookies-vs-tokens-the-definitive-guide [4] : https://tools.ietf.org/html/rfc6819#section-5.4.1
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 "JWT authentification" ; ont une apparence similaire en ce qui concerne 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 précise 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 auprès de ce que l'on appelle un serveur d'autorisation.
La véritable différence est donc que JWT n'est qu'un format de jeton, tandis que OAuth 2.0 est un protocole (qui peut utiliser 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 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 genre 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 du jeton CSRF dans JWT est inutile.