Discussion :

[Daïmanu]

Bonjour à tous.

Le projet sur lequel je travaille a une architecture REST, le serveur traite des requêtes stateless dont certaines requièrent une authentification.

J'ai remarqué que chaque requête est automatiquement accompagnée d'un cookie JSESSIONID.
Je n'ai pas encore implémenté le système d'authentification REST, mais ce cookie se substitue à l'authentification tout seul, puisque quand il est présent, les pages restreintes sont accessibles, et quand je le supprime, je n'ai plus accès à ces pages.

Je me demande si laisser ce cookie est architecturalement correct, puisque par définition il n'y a pas de session en REST, non
Si c'est incorrect, comment je peux empêcher sa génération

Merci.

[Daïmanu]

Pour la désactivation des cookies, je m'en suis sorti avec ce post. Ça ne supprime pas le cookie, mais sa présence n'inhibe plus le système d'authentification.

Mais je sais pas si c'est correct ou pas de supprimer ce cookie JSESSIONID.

[Daïmanu]

Bon, j'ai bien avancé sur le système d’authentification.

Mais j'ai une question de sécurité.

Le fait d'être authentifié ajoute des données au header HTTP et stocke des données en local, dans le navigateur.
Ma question est quel est le meilleur moyen de conserver et de sécuriser ces données parmi cookie, JWT, Basic Authentication ou OAuth (ou autre) ?

La Basic Authentication est simple, mais pas sécurisée.
Le cookie est isolé et n'est pas accessible par d'autre sites, mais certaines personnes indiquent que ce n'est pas très REST-like.
Le JWT est controversé et un peu lourd je trouve.
OAuth je ne sais pas ce que ça vaut.

D'après vous est-ce qu'il y a un système qui se démarque des autres ?
Par défaut je pense passer par des cookies.

[fr1man]

La basic authentication n'est pas mauvaise, mais tu dois l'utiliser avec https.
Le cookie est une bonne idée, mais il faut le signer avec une clé connue seulement du serveur, de manière à ce que ce cookie ne puisse pas être modifié ou généré par un malandrin.

[tchize_]

La Basic Authentication est simple, mais pas sécurisée.

Il a la sécurité que lui accorde le client, pour autant que le serveur soit accédé en https

Le cookie est isolé et n'est pas accessible par d'autre sites, mais certaines personnes indiquent que ce n'est pas très REST-like.

le cookie n'est qu'un header http spécifique au final. ce n'est jamais un soucis d'ajouter des header à des services REST. Ce qui serait un problème, ce serait un cookie de session

Le JWT est controversé et un peu lourd je trouve.

Ce n'est qu'un moyen de prouver tes credentials avec un document signé. Si tu l'implémente toi même, tu va vite faire des erreurs de sécurité. Au passage, faudra bien transférer ton JWT au serveur, donc avec un cookie ou des header

OAuth je ne sais pas ce que ça vaut.

les protocole types oauth sont utilisé quand on désire que le serveur d'authentification / authorisation soit séparé du serveur fournissant le service. C'est basé sur JWT.

D'après vous est-ce qu'il y a un système qui se démarque des autres ?
Par défaut je pense passer par des cookies.

J'éviterais le JWT maison (trop de risques de merder) et le cookie de session (on ne crée pas une session pour du rest). Pour le reste ça dépend de tes besoins.

[Daïmanu]

Bonjour.

Le HTTPS est obligatoire on est d'accord.

Ce que je n'aime pas avec le Basic Auth, c'est que les credentials sont conservés par le client ne sont à priori pas chiffrés. On pourrait faire en sorte que ça le soit, mais ça serait réinventer la roue.

J'aime bien l'idée du cookie ou du JWT chiffré par le serveur, mais qu'est-ce qui se passe si quelqu'un arrive à dérober le cookie / token ? On peut révoquer le token, mais c'est une intervention manuelle, non ?

J'ai l'impression que je me prends tellement la tête

En tous cas merci, j'y vois un peu plus clair, je vais potasser tout ça.

[tchize_]

J'aime bien l'idée du cookie ou du JWT chiffré par le serveur, mais qu'est-ce qui se passe si quelqu'un arrive à dérober le cookie / token ? On peut révoquer le token, mais c'est une intervention manuelle, non ?

Oui, d'ou le fait qu'il faut éviter les solutions "maisons". oauth mitige ça en utilisant deux tokens: un qui est utilisé pour dialoguer avec le service. Ce sont des tokens avec une durée de vie courte. En cas de vol, il faut vite les utiliser avant qu'il ne soient plus valides. Et un autre à longue durée de vie, utilisé pour communiquer avec le serveur oauth et obtenir les tokens à faible durée de vie. Comme ils ne sont envoyés qu'au serveur auth, moins de risques de fuite.

Dans tous les cas ces tokens ne durent pas plus de quelques jours. Après il faut retapper le mot de passe.

[Daïmanu]

Je reviens vers vous car je me suis tourné vers une architecture OAuth2.

J'essaye donc de trouver des tutoriels sur le net mais j'ai énormément de mal à comprendre comment utiliser OAuth2 avec Spring.

J'ai suivi ce tutoriel et ce que j'en ai compris :

• @EnableResourceServer définit le serveur comme serveur de ressources et le sécurise en conséquence
• @EnableAuthorizationServer définit le serveur comme serveur d'authentification et le sécurise en conséquence
• Leurs méthodes configure() permettent de définir quels urls seront accessibles par qui

Seulement, contrairement au premier test où je m'attends à avoir un 401, j'arrive à interroger mes contrôleurs et à avoir des résultats.
Et au contraire, je n'arrive pas à m'identifier sur /oauth/token pour récupérer un jeton d'accès. Je teste avec les identifiants admin/admin123 et les comptes de ma base de données, j'ai toujours un code 401 - Bad credentials. Il y a quelque chose à faire en particulier ?

Autre question : Est-ce qu'on peut combiner un serveur de ressources et un serveur d'authentification (avec @EnableResourceServer / @EnableWebSecurity et @EnableAuthorizationServer) dans un même projet ?

Merci pour vos éclaircissements !

Cordialement.

[JeitEmgie]

Autre question : Est-ce qu'on peut combiner un serveur de ressources et un serveur d'authentification (avec @EnableResourceServer / @EnableWebSecurity et @EnableAuthorizationServer) dans un même projet ?

voir le bas de la page
https://docs.spring.io/spring-boot/d...-security.html