« Oauth2 lecture » : différence entre les versions

Aucun résumé des modifications
Aucun résumé des modifications
Ligne 50 : Ligne 50 :


- Le jeton de renouvellement (Refresh Token ) : Utilisé pour demander de prolonger l’accès à une ressource ; envoyé sur demande d’une application qui détient déjà un jeton d’accès valide.
- Le jeton de renouvellement (Refresh Token ) : Utilisé pour demander de prolonger l’accès à une ressource ; envoyé sur demande d’une application qui détient déjà un jeton d’accès valide.
</pre>
=== VALIDATION access_token ===
<pre>
VALIDATION access_token par RS quand demande du CLIENT
=> ipmplique une interraction entre RS et AS
sur AS une extremite=>"tokeninfo"
Le serveur de ressource (RS) n’est pas directement lié au serveur d’autorisation (AS).
Dans ce cas, il existe deux familles de méthodes :
- la première consiste à authentifier le jeton d’accès par interrogation du serveur d’autorisation (introspection).
- la deuxième consiste à ce que l’application tierce assure localement l’authentification du jeton d’accès.
la validation à l’aide de cryptage asymétrique (signature).
jeton d’identité (ID Token) fondé sur JWT
</pre>
</pre>


Ligne 132 : Ligne 148 :
Qu'elles appellent des services internes ou externes, toutes les API ne doivent utiliser que les revendications affirmées par le serveur centralisé et ne doivent pas ajouter d'informations supplémentaires ni émettre de jetons. La gestion centralisée des réclamations vous permet de contrôler les informations circulant entre les API pour vous assurer qu'elles ne divulguent pas de données excédentaires.
Qu'elles appellent des services internes ou externes, toutes les API ne doivent utiliser que les revendications affirmées par le serveur centralisé et ne doivent pas ajouter d'informations supplémentaires ni émettre de jetons. La gestion centralisée des réclamations vous permet de contrôler les informations circulant entre les API pour vous assurer qu'elles ne divulguent pas de données excédentaires.
</pre>
</pre>


=== OpenID Connect ===
=== OpenID Connect ===
Ligne 171 : Ligne 186 :
- Vérification de l’origine de la requête reçue par un serveur de ressource.
- Vérification de l’origine de la requête reçue par un serveur de ressource.
</pre>
</pre>
 
extremite=>"introspect"<br />
extremite=>"introspect"
https://oa.dnc.global/-API-OpenID-Connect-Points-d-extremite-.html#apiopenidconnectintrospectionintrospectionendpoint
https://oa.dnc.global/-API-OpenID-Connect-Points-d-extremite-.html#apiopenidconnectintrospectionintrospectionendpoint


Ligne 221 : Ligne 235 :
https://oa.dnc.global/-Sujets-communs-a-Oauth-2-et-OpenID-Connect-.html#definitiondesscopesoidcetgeneralitessurleurutilisationparlesapplications
https://oa.dnc.global/-Sujets-communs-a-Oauth-2-et-OpenID-Connect-.html#definitiondesscopesoidcetgeneralitessurleurutilisationparlesapplications


=== VALIDATION access_token ===
<pre>
VALIDATION access_token par RS quand demande du CLIENT
=> ipmplique une interraction entre RS et AS
sur AS une extremite=>"tokeninfo"
Le serveur de ressource (RS) n’est pas directement lié au serveur d’autorisation (AS).
Dans ce cas, il existe deux familles de méthodes :
- la première consiste à authentifier le jeton d’accès par interrogation du serveur d’autorisation (introspection).
- la deuxième consiste à ce que l’application tierce assure localement l’authentification du jeton d’accès.
    la validation à l’aide de cryptage asymétrique (signature).
    jeton d’identité (ID Token) fondé sur JWT
</pre>