Discussion :

[duke666]

bonjour tout le monde,

Je m'intéresse pour protéger au mieux une API REST (données hautement sensible)
Cette API REST doit être accessible par plusieurs applications web.
l'authentification de base est : login + password
(et de pouvoir en fonction des rôles users de permettre ou pas la création ou consultation via l'API)


Je regarde entre JWT et Oauth2 (ce dernier me semble compliqué).

la meilleure technique ?
(1) JWT + SSL
(2) Oauth2 + JWT + SSL


quelle est la technique la plus sécurisé et la souple ?


en fait, je ne vois pas l'utilité de Oauth2 à part pour aller sur facebook…

[sneb5757]

Hello

Oauth2 n'est pas envisageable car ce n'est pas adapté à ton cas d'utilisation. Oauth2 est utilisé pour accéder à des resources d'un utilisateur qui est hébergé par un tiers . Admettons tu as une application Web. Tu souhaite accéder aux informations de profil d'un de tes utilisateurs. Ca se passera de la façon suivante :
1) Tu redirige ton utilisateur vers facebook
2) ton utilisateur s'authentifiera sur facebook
3) Il donnera son consentement pour que ton application puisse accéder à ses information de profil facebook
4) Il sera redirigé vers ton application avec un code
5) Ton application echangera ce code pour obtenir un token d'access de la part de facebook
6) Ton application utilisera ce token d'acces pour intérroger l'API facebook

Comme tu le vois ça ne sert absolument à rien pour authentifier les utilisateurs pour utiliser ta propre API. L'idée est d'utiliser JWT. Quand un utilisateur s'est authentifier à ton appli, cette dernière devrait fournir un token JWT. Ce token JWT doit :
- Avoir une durée de vie limité
- Avoir une signature que tu vas vérifier à chaque fois que tu reçois une requête sur une route de ton API
Je suis pas exhaustif il y'a une super doc sur le sujet ici : https://www.owasp.org/index.php/JSON...Sheet_for_Java

Le token JWT peut être transmis de deux façon par les clients :
- Soit via le header Authorization.
- Soit via des cookies ( pas des cookies de session)

J'aime bien les cookies car dans le cadre de client en javascript tournant dans un navigateur cela permet d'avoir un moyen plus sûre de stocker les JWT. En effet l'utilisation d'un header d'authorization oblige les clients tournant dans un navigateur de stocker les JWT dans le local storage ou le session storage. Ces deux espaces de stockages sont vulnérables aux attaques XSS. Alors qu'en utilisant le mécanisme des cookies il est possible d'utiliser les mécanismes de tag suivant :

• HttpOnly : Prévient l'accès par Javascript aux cookies. Ainsi en cas de faille XSS les cookies ne risquent pas d'être volés
• Secured : Prévient le cookie d'être transmis sur un canal non SSL ( très utilise contre certaines attaques de l'homme du milieu )
• SameSite : Prévient les attaques de type CSRF

Plus d'info ici : https://blog.dareboost.com/fr/2016/1...cure-httponly/
Note que l'utilisation de cookie n'implique pas forcémment de session donc ne casse pas l'architecture REST. Ici il s'agit d'un moyen pour transmettre le token JWT entre ton client et ton server.