Rest - Questions autour de l'authentification JWT et Oauth2

Bonjour,
J'ai une appli avec des services REST et une authentification qui permet la création d'un token JWT qui est ensuite envoyé par le client à chaque requête. Ce token expire au bout de 20 minutes. Je gère la récupération du token, la vérification du token et la restriction par rôle grâce à Spring security.

J'ai cependant quelques questions:
- J'ai vu des exemples où le ou les roles de l'utilisateur étaient mis dans le token puis récupérés du token côté serveur. Le token contient donc les infos de l'utilisateur y compris son rôle ce qui permet d'être stateless. Le token étant signé, il ne peut pas être modifié pour par exemple se mettre dans un autre rôle (ex: un role d'admin) mais n'est-ce pas risqué d'avoir le rôle en clair dans le token? Je préfère avoir juste l'identifiant et aller chercher à chaque fois en base le rôle même si du coup je ne suis plus stateless.
- Actuellement j'ai seulement un token mais j'ai vu qu'on pouvait utiliser Oauth2 et gérer 2 tokens: le token principal qui a une durée d'expiration pus courte (ex: 2 minutes) et un token pour le refresh qui a une durée d'expiration plus longue (ex: 30 minutes). Cependant, je ne vois pas ce que cela apporte car une personne malintentionnée récupérant les 2 tokens pourra toujours se connecter jusqu'à l'expiration du token de refresh. Pouvez-vous m'expliquer en quoi cela serait plus sûr avec Oauth2?

Merci d'avance pour votre retour.

Citation:

---

Envoyé par philou44300

mais n'est-ce pas risqué d'avoir le rôle en clair dans le token?

---

Le risque serait éventuellement que l'utilisateur se découvre des droits qu'il ignorait. A Priori la liste des droits que possède un utilisateur n'a rien de secret. Maintenant c'est sur que si tu défini un rôle GROS_CHIEUR pour marquer les gens ayant reçu un blâme sur le forum, ça va te poser des problèmes diplomatiques.

Citation:

---

Envoyé par philou44300

Pouvez-vous m'expliquer en quoi cela serait plus sûr avec Oauth2?

---

Alors oauth2 ne sera pas en lui même "plus sûr" pour ton application. C'est surtout un système qui te permet d'avoir l'authentification sur un serveur et les services sur un autre. Ce système est basé sur le postulat que

=> L'utilisateur fait confiance au service oauth2 pour assurer la confidentialité de son mot de passe et de garantir son identité
=> L'utilisateur discute avec plusieurs applications dont il n'est pas trop sûr du niveau de qualité.

Exemple typique: je fais confiance à google pour m'authentifier et assurer mon identité. L'application de la pizzeria au coin de la rue, je me doute bien qu'elle a été codée pour pas trop cher avec le minimum syndical.

Le token a donc une durée de vie très courte, afin que si il est intercepté entre chez toi et la pizzeria, ou par la pizzeria elle même, son usage sera très limité: une fenêtre de 2 minutes où on pourra se faire passer pour toi et commander de la pizza. Un token JWT simple avec un timeout de 40 minute nourrirait beaucoup plus de personnes.

Le refresh token, par contre, il n'est échangé qu'entre toi et le serveur d'authentification. Un canal réputé sûr (https) et de confiance (tu connais google, t'y a créé ton compte).
Enfin, le refresh token ne pouvant qu'être échangé contre un token et ne pouvant pas servir directement à s'authentifier, ça permet de gérer la fermeture de la session (logout). Le serveur oauth2 refusant à partir de là toute forme d'échange même si le refresh token n'est pas expiré.

Bien entendu aussi, un outil oauth2 largement répandu avec une population de dev active dessus aura surement des chances d'être plus sûr qu'une authentification maison.

Merci pour le retour.

Pour le role dans le token, ce dont j'ai peur c'est que si un hacker l'intercepte, il saura à quel role est lié l'utilisateur. Si le role l'intéresse (ex: admin), alors il ciblera le compte...

Je n'avais pas compris que pour Oauth2 le token refresh était géré par une autre entité qui est réputée sûre. Les 2 tokens sont-ils tout de même à envoyer dans chaque requête à notre serveur ou bien on envoi que notre token? Le token refresh est-il géré par l'API pour sa génération et son management?

En fait je me dis que si un hacker arrive à récupérer les 2 tokens dans une requête ou une réponse de notre service car l'échange est mal sécurisé, alors il pourra tout de même se faire passer pour l'utilisateur et cela ne changerait donc rien par rapport à avoir un seul token.

Citation:

---

Envoyé par philou44300

Pour le role dans le token, ce dont j'ai peur c'est que si un hacker l'intercepte, il saura à quel role est lié l'utilisateur. Si le role l'intéresse (ex: admin), alors il ciblera le compte...

---

Vu qu'en général ce compte s'appellera "admin", peu de chance que ça joue mais je comprends ton point de vue. Ceci dit, si l'interception du token te pose soucis, raison de plus de lui donner un très courte durée de vie.

Citation:

---

Envoyé par philou44300

En fait je me dis que si un hacker arrive à récupérer les 2 tokens dans une requête ou une réponse de notre service car l'échange est mal sécurisé, alors il pourra tout de même se faire passer pour l'utilisateur et cela ne changerait donc rien par rapport à avoir un seul token.

---

C'est le principe, ton serveur ne reçoit jamais le refresh token, seulement le access token. Le refresh token n'est échangé qu'avec le serveur auth, ce qui limite les risques de fuite. Ce serveur là doit être sécurisé parfaitement pour éviter les interception.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

browser ====(mot de passe)==> https://auth.service.com browser <==(refresh token)=== https://auth.service.com     obtenir un token browser ===(refresh token)==> https://auth.service.com browser <===(access token)=== https://auth.service.com (opération à refaire à chaque fois qu'on a besoin d'un access token et que celui qu'on avait a expiré)   accéder à ton service browser ====(access token)==> https://www.tonservice.com browser <======(données)===== https://www.tonservice.com

---

Pour résumer: on peux (un peu) se permettre de perdre le access token dans la nature, il meurt vite. Mais on ne peux pas se permettre de perdre le refresh token. L'access token est utilisé beaucoup, avec beaucoup de site, le refresh token n'est utilisé que quand nécessaire et uniquement avec le serveur auth.

Pour renforcer la sécurité, il existe aussi l'option d'avoir un refresh token à usage unique. A chaque demande d'un nouvel access token, on reçois un nouveau refresh token. Si le refresh token est intercepté il n'est pas réutilisable.

L'idée ici est de mitiger les risque lié à l'utilisation uniquement d'un secret partagé entre le client et le serveur (session id, jwt token, etc). Dis toi que si on arrive à intercepter le traffic entre ton browser et ton serveur auth pour récupérer le refreshtoken, alors on a déjà aussi récupérer les paquets avec le user/pass, donc la sécurité des token deviens futiles :)

Effectivement ca se tient. Pour le profil, cela ne s'appelle jamais admin dans mes applis persos d'où ma question sur le rôle s'il est mis en clair dans le token même si je peux lier un role qui s'appelle ROLE_BASE par exemple avec des droits d'admin et ROLE_USER pour un simple utilisateur pour "tromper" la personne qui regarderait le contenu du token :). Ou bien j'avais pensé à chiffrer en AES cette donnée (ou carrément tout le token) avant de la mettre dans le token et de la déchiffrer avant de l'exploiter. Est-ce que cela ne serait pas mieux pour être stateless et plus sécurisé?

J'ai regardé des exemples avec Spring security et Oauth2 mais je ne comprend pas la configuration et le fonctionnement car il y a peu d'explications et plus de code. On y créé à chaque fois 2 types de serveurs: un d'authentification (qui gère juste l'access token ou bien aussi le rafraichissement avec le refresh token?) et un de ressource. Le serveur d'authentification est donc aussi de notre côté ou bien c'est autre part (comme chez Google par exemple que tu citais plus haut)?

Si c'est chez nous il peut aussi y avoir un risque que cela soit mal sécurisé non? (et du coup on retomberait sur le même problème de sécurité qui peut concerner l'application elle même).

Si j'ai compris, pour une application que seul des employés peuvent utiliser (pour laquelle on veut avoir une liste définie d'utilisateur associée à des roles bien définis), Oauth2 ne peut pas être utilisé car on ne veut pas forcément passer par un serveur d'authentification externe et on veut maitriser les utilisateurs, les droits et les rôles au sein de notre appli (donc avec ces infos en BD). Par contre, pour un forum par exemple qui peut être consulté par tout le monde et où tout le monde pourrait intervenir mais sur lequel on veut authentifier tout de même l'utilisateur pour qu'il ne soit pas anonyme, on peut utiliser Oauth2 afin qu'il se puisse se connecter avec son compte google ou facebook.

Enfin, si le serveur qui fabrique le refresh token est par exemple chez Google et qu'il utiliserait donc un compte Google pour s'authentifier, comment je fais le lien avec son compte au sein de mon application?

Citation:

---

Envoyé par philou44300

J'ai regardé des exemples avec Spring security et Oauth2 mais je ne comprend pas la configuration et le fonctionnement car il y a peu d'explications et plus de code. On y créé à chaque fois 2 types de serveurs: un d'authentification (qui gère juste l'access token ou bien aussi le rafraichissement avec le refresh token?) et un de ressource. Le serveur d'authentification est donc aussi de notre côté ou bien c'est autre part (comme chez Google par exemple que tu citais plus haut)?

---

Le serveur d'authentification est un serveur séparé que tu sécurise bien correctement. Ca permet de te décharger de cette tâche dans ton serveur applicatif qui peut lui se concentrer sur la logique business. Pour ce que je comprend de ta description des exemples spring, ils créent un serveur oauth2 de toutes pièces en utilisant spring. Il est préférable de t'orienter vers des outils oauth2 déjà existants à mon avis (l'intérêt étant justement d'y gagner du temps), ça t'évitera de t'emmerder pour cette partie là. Par exemple tu peux utiliser keycloak (http://www.keycloak.org)que tu installe dans ta société comme serveur oauth2. C'est pas mal complet et ils a déjà des docs sur l'intégration dans un client Spring. (Ton app web est un client pour un serveur oauth).

Citation:

---

Si j'ai compris, pour une application que seul des employés peuvent utiliser (pour laquelle on veut avoir une liste définie d'utilisateur associée à des roles bien définis), Oauth2 ne peut pas être utilisé car on ne veut pas forcément passer par un serveur d'authentification externe et on veut maitriser les utilisateurs, les droits et les rôles au sein de notre appli (donc avec ces infos en BD). Par contre, pour un forum par exemple qui peut être consulté par tout le monde et où tout le monde pourrait intervenir mais sur lequel on veut authentifier tout de même l'utilisateur pour qu'il ne soit pas anonyme, on peut utiliser Oauth2 afin qu'il se puisse se connecter avec son compte google ou facebook.

---

Google / facebook n'est qu'un exemple. D'ailleurs il est assez incomplet car google / facebook n'exposera aucun role alors que le serveur oauth de ton entreprise lui devrait gérer ça. OAuth peut très bien être utilisé dans une entreprise, aussi bien que SAML qui est une alternative basée sur des tokens XML. L'avantage étant justement que tu a un seul système d'authentification pour toutes tes applis d'entreprise, qui protège tout. Pas besoin de créer des compte sur chaque appli de l'entreprise, on gère tout ça de manière centrale. Le protocole oauth2 étant standardisé, tu peux théoriquement passer d'une serveur à un autre facilement si tu veux changer d'outils dans le futur.

Citation:

---

Enfin, si le serveur qui fabrique le refresh token est par exemple chez Google et qu'il utiliserait donc un compte Google pour s'authentifier, comment je fais le lien avec son compte au sein de mon application?

---

Encore une fois google / facebook n'est qu'un exemple. Le principe étant là qu'on utilise google que pour authentifier par pour authoriser. Donc l'utilisateur qui crée un compte dans ton appli le faire à partir de google. Par la suite ton appli viens mettre au dessus des rôles qu'elle gère elle même. Mais pour des employés d'une entreprise tu n'utilisera pas ça (google) à priori. Sauf si justement l'entreprise à pris un compte google d'entreprise pour y mettre tout ses users :-) Mais dans ce cas là je recommenderais quand même de mettre une serveur oauth interne à l'entreprise, juste de permettre à ce serveur d'éventuellement déléguer à google. Oui on peux chainer l'un derrière l'autre les systèmes oauth. Exemple: j'ai un serveur interne oauth2 qui permet d'utiliser stackoverflow. Je clique sur "stackoverflow" qui m'affiche son propre login où se trouve un bouton "google" que j'utilise. Au final:

pour ton appli buisness tu est un user oauth2 de ton serveur d'entreprise, avec des roles bien définis par l'admin
pour ton serveur oauth2 tu es un user interne, mais stackoverflow assure ton identité
pour stackoverflow, tu es un utilisateur stackoverflow, mais google assure ton identité.


bon c'est des cas extrême hein :D




Pour résumer, les avantages que je vois perso d'un serveur type Oauth2 mis en place dans une société pour les outils interne:

Système SSO: pas besoin de se réauthentifier pour passer d'une app couverte par le même realm à une autre
Gestion centrale des mots de passe: plus pratique pour l'admin
Tu ne dois pas coder: interface de login, de mot de passe perdu, d'enregistrement, de logout, d'administration des droits -> Et ça en bouffe du temps ces conneries :)
Les sécurités sont déjà en place sur le serveur: évite de nombreuses erreurs de débutant dans la gestion des sessions / de l'authentification / du CORS

Le gros inconvénient que je vois, c'est quand on part d'une appli déjà existante, c'est qu'il faut repenser ton appli autrement: des utilisateurs dont tu ne connais rien peuvent potentiellement tout d'un coup se pointer authentifié car on les a ajouté au serveur oauth2. Tu n'es donc plus mis au courant dans ton appli de la création de users.

Merci pour le retour et toutes ces explications. Je regarderai dès que j'ai du temps pour keycloak :).