« Oauth2 lecture » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 15 : | Ligne 15 : | ||
vous pouvez avoir votre serveur d'autorisation et votre serveur de ressources dans la même application. Quelle que soit la façon dont vous décidez de le faire, cela dépend de votre style. Cela n'affecte pas la fonctionnalité de vos serveurs. | vous pouvez avoir votre serveur d'autorisation et votre serveur de ressources dans la même application. Quelle que soit la façon dont vous décidez de le faire, cela dépend de votre style. Cela n'affecte pas la fonctionnalité de vos serveurs. | ||
</pre> | </pre> | ||
=== OAuth 2.0 est un système d’autorisation === | |||
<pre> | |||
pas de signature de jeton | |||
on peut "faire confiance" aux applications clientes (par exemple, l’URL de retour est "codée en dur" dans l’application). | |||
=>sécurisés que dans un espace propriétaire (corporate realm). | |||
Pour être utilisés dans un espace ouvert, il manque une signature pour authentifier. | |||
OpenID Connect comme un protocole construit sur OAuth 2.0 | |||
OpenID Connect a pour but d’apporter les fonctions nécessaires à l’identification de l’utilisateur final et de l’application cliente, tout en assurant la sécurité grâce à la signature du jeton. | |||
OpenID Connect complète les fonctionnalités d’OAuth 2.0 pour apporter, avec le 5jeton JWT signé ou JWS) => jeton d’identité (ID Token), des informations sûres sur l’application cliente, la portée de l’autorisation (scope) et, le cas échéant, sur l’utilisateur connecté à l’application cliente. | |||
Cependant, vérifier la signature du jeton ne suffit pas. Il ne faut pas écarter la possibilité d’un vol de jeton qui sera présenté par une application étrangère. | |||
Seul le flux Authorization Code appliqué à des applications clientes de type web (avec back-end) peut être considéré comme sûr. | |||
OAuthSD expose un point d’entrée d’introspection qui permet de vérifier aussi bien les jetons d’accès d’OAuth 2.0 que les jetons d’identité d’OpenID Connect. | |||
</pre> | |||
https://oa.dnc.global/-OAuth-2-0-.html#validationdujetondaccesparuneressourceprotegee | |||
<pre> | |||
Le jeton peut être sur le RS localement ou sur le AS introspection | |||
il faut faire valider le jeton (localement ou par introspection) par l’application tierce => | |||
signature du jeton JWT (JSON Web Token). | |||
</pre> | |||
https://oa.dnc.global/-JSON-Web-Token-JWT-JWS-.html#jsonwebtokenjwt | |||
=== Jeton (Token) === | === Jeton (Token) === | ||
| Ligne 29 : | Ligne 54 : | ||
=== Jeton d'identification === | === Jeton d'identification === | ||
google exemple | google exemple | ||
https://developers.google.com/identity/protocols/oauth2/openid-connect?csw=1#validatinganidtoken | [https://developers.google.com/identity/protocols/oauth2/openid-connect?csw=1#validatinganidtoken google exemple] | ||
<pre> | <pre> | ||
La validation d'un jeton d'identification nécessite plusieurs étapes : | La validation d'un jeton d'identification nécessite plusieurs étapes : | ||
| Ligne 66 : | Ligne 91 : | ||
Pbjectifs, le contrôle de l’accès des utilisateurs aux applications et des applications aux ressources protégées, constituent l’angle d’attaque | Pbjectifs, le contrôle de l’accès des utilisateurs aux applications et des applications aux ressources protégées, constituent l’angle d’attaque | ||
flux de code avec autorisation = authorization code | flux de code avec autorisation = authorization code de serveur a serveur l'application cliente est executée sur le serveur d'authorisation meme zone de confiance (car meme ip) | ||
si l'application est sur un user agent (SPA, application cliente mobile native, le serveur ne peut pas avoir confiance, elle ne peut pas protéger ses identifiants ) | si l'application est sur un user agent (SPA, application cliente mobile native, le serveur ne peut pas avoir confiance, elle ne peut pas protéger ses identifiants ) | ||
| Ligne 108 : | Ligne 132 : | ||
</pre> | </pre> | ||
=== OpenID Connect === | === OpenID Connect === | ||