« Oauth2 lecture » : différence entre les versions
Aucun résumé des modifications |
Aucun résumé des modifications |
||
| Ligne 7 : | Ligne 7 : | ||
RS = serveur de ressource = application tierce = fournisseur de service | RS = serveur de ressource = application tierce = fournisseur de service | ||
Client = Relying Party | Client = Relying Party | ||
=== vocabulaire === | |||
<pre> | |||
-Le Resource Provider expose des ressources, publiques ou privées, sur le Web via une API REST bien designée. Cher lecteur, il s’agit probablement de votre produit ! | |||
-Le Développeur veut utiliser ces ressources afin de fournir un nouveau service via son application. | |||
-L’Utilisateur utilise vos services, et a peut-être déjà suffisamment de droits pour consommer certaines ressources privées. Et il voudrait y accéder via l’application du développeur décrit précédemment. | |||
-L’Identity Provider sait qui est qui, et sait comment savoir qui est qui. Vous avez suivi ? Il s’agit peut-être aussi de vous, cher lecteur. Beaucoup de resource providers sont aussi des identity providers (pensez à Google, à Facebook…). Si vous stockez votre base d’utilisateurs dans un LDAP d’entreprise, vous n’êtes pas loin d’avoir à votre disposition un identity provider. | |||
</pre> | |||
<pre> | <pre> | ||
| Ligne 14 : | Ligne 22 : | ||
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> | |||
=== la brique "d'authentification" a 3 rôles === | |||
<pre> | |||
fournisseur d'identité : qui est l'utilisateur ? ses informations ? Nom, prénom, username, 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 ? | |||
</pre> | </pre> | ||
| Ligne 254 : | Ligne 269 : | ||
Les clients DOIVENT valider le jeton ID dans la réponse au jeton de la manière suivante : | Les clients DOIVENT valider le jeton ID dans la réponse au jeton de la manière suivante : | ||
</pre> | </pre> | ||
https://oa.dnc.global/-OpenID-Connect-6-.html#validationdujetondidentiteidtokenjwtsigneoujws | [https://oa.dnc.global/-OpenID-Connect-6-.html#validationdujetondidentiteidtokenjwtsigneoujws Validation du jeton d’identité ID Token (JWT signé ou JWS)] | ||
=== code d'autorisation === | === code d'autorisation === | ||