« Oauth2 lecture » : différence entre les versions
Aucun résumé des modifications |
|||
| Ligne 29 : | Ligne 29 : | ||
Authentification: Demander à l'utilisateur de s'authentifier par un moyen X (login/mot de passe dans une base de données, un LDAP/AD, mais aussi via son token Kerberos, etc....) | Authentification: Demander à l'utilisateur de s'authentifier par un moyen X (login/mot de passe dans une base de données, un LDAP/AD, mais aussi via son token Kerberos, etc....) | ||
Autoriser: OK l'utilisateur existe, il s'est authentifié, mais a-t-il le droit d'accéder à l'application ? | Autoriser: OK l'utilisateur existe, il s'est authentifié, mais a-t-il le droit d'accéder à l'application ? | ||
</pre> | |||
=== Authentifier l’application === | |||
[https://oa.dnc.global/-Authentifier-l-application-.html#verificationdeloriginedelarequeterecueparunserveurderessource Vérification de l’origine de la requête reçue par un serveur de ressource] | |||
<pre> | |||
Le serveur de ressource (Resource Server) doit pouvoir vérifier la légitimité du détenteur du token. | |||
Mais comment ? | |||
La spécification décrit clairement cette limitation (§10.3) : | |||
Cette spécification ne fournit aucune méthode pour que le serveur de ressources s’assure qu’un jeton d’accès qui lui est présenté par un client donné a été émis pour ce client par le serveur d’autorisation. | |||
"vous pouvez utiliser les jetons d’accès JWT si vous avez des systèmes distribués et que vous devez valider l’authenticité d’un jeton auprès de plusieurs parties sans avoir à passer un appel réseau. | |||
Par exemple, un jeton est attribué par le serveur d’autorisations. Ce jeton est un jeton Web JSON signé par la clé privée du serveur d’autorisations. Les serveurs de ressources (vers lesquels les appels d’API sont effectués) sont répartis dans le monde entier et exécutent plusieurs applications. Tant que les serveurs de ressources disposent de la clé publique du serveur d’autorisations, qui n’a pas besoin d’être sécurisée, ils peuvent valider les jetons rapidement sans aucun appel réseau. Les jetons n’ont même pas besoin d’être persistés." | |||
</pre> | </pre> | ||
| Ligne 302 : | Ligne 317 : | ||
=== 2022-04-25 === | === 2022-04-25 === | ||
https://www.mechantblog.com/2018/12/token-api-macaroon-jwt/ | |||
<pre> | <pre> | ||
Vu que le secret peut être asymétrique, Il est possible de créer une clé privée/publique par utilisateur. On génère un token avec la clé privée, et on enregistre la clé publique dans la base de données. Cette clé n’est pas critique et peut être volée sans rien compromettre. Ce qui donnerait ceci: | |||
Récupération du token dans le header (ou un cookie, une session, etc…) | |||
Extraction du champs userId dans le payload | |||
Récupération de la clé publique liée à cet utilisateur | |||
Vérification du token avec la clé publique | |||
Si c’est bon, le token est confirmé et on peut faire confiance aux infos du payload | |||
RS256 utilise le cryptage à clé publique pour signer le jeton. La signature (hachage) sera créée à l'aide de la clé privée et pourra être vérifiée à l'aide de la clé publique. Ainsi, pas besoin de clé privée ou de secret client à stocker sur le serveur principal, mais le serveur principal récupère la clé publique à partir de l'URL de configuration openid de votre locataire (https://[tenant]/.well-known/openid -configuration) pour vérifier le jeton. Le paramètre KID à l'intérieur de access_toekn sera utilisé pour détecter la bonne clé (publique) à partir de la configuration openid. | |||
</pre> | |||
La | |||
=== 2022-04-28 === | === 2022-04-28 === | ||