« Oauth2 lecture » : différence entre les versions
Aucun résumé des modifications |
|||
| (4 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 82 : | Ligne 82 : | ||
- Le jeton d’accès (Access Token) : Permet au serveur d’une ressource protégée d’autoriser une application cliente à y accéder. Ce jeton est envoyé par l’application cliente en tant que paramètre ou en tant que header dans la requête vers le serveur de ressources. Il a une durée de vie limitée qui est définie par le serveur d’autorisation. | - Le jeton d’accès (Access Token) : Permet au serveur d’une ressource protégée d’autoriser une application cliente à y accéder. Ce jeton est envoyé par l’application cliente en tant que paramètre ou en tant que header dans la requête vers le serveur de ressources. Il a une durée de vie limitée qui est définie par le serveur d’autorisation. | ||
- 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> | </pre> | ||
| Ligne 253 : | Ligne 253 : | ||
=== Forme de la demande d’Introspection === | === Forme de la demande d’Introspection === | ||
'''Contrôle de l’accès''' | |||
<pre> | <pre> | ||
Les demandes adressées au point de terminaison d’introspection doivent être authentifiées avec les informations d’identification du client (Client Credentials Grant) ou autorisées avec un jeton d’accès au porteur (Bearer Token). | Les demandes adressées au point de terminaison d’introspection doivent être authentifiées avec les informations d’identification du client (Client Credentials Grant) ou autorisées avec un jeton d’accès au porteur (Bearer Token). | ||
En conséquence, l’application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d’authentification | En conséquence, l’application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d’authentification | ||
</pre> | |||
Client Credentials Grant | '''Client Credentials Grant''' | ||
<pre> | |||
C’est l’approche la plus simple et celle qui est recommandée. | C’est l’approche la plus simple et celle qui est recommandée. | ||
L’application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d’authentification [1]. | L’application appelante (ou le serveur de ressource) doit être enregistrée comme cliente sur le serveur d’authentification [1]. | ||
L’authentification est effectuée en utilisant l’authentification HTTP Basic (cf. section 2.3.1 de OAuth 2.0 [RFC6749]). Les identifiants client_id et client_secret sont ceux qui ont été définis lors de l’inscription de l’application cliente sur le serveur. | L’authentification est effectuée en utilisant l’authentification HTTP Basic (cf. section 2.3.1 de OAuth 2.0 [RFC6749]). Les identifiants client_id et client_secret sont ceux qui ont été définis lors de l’inscription de l’application cliente sur le serveur. | ||
</pre> | |||
Bearer Token | '''Bearer Token''' | ||
<pre> | |||
Cette approche nécessite un jeton d’accès pour autoriser la demande d’introspection. | Cette approche nécessite un jeton d’accès pour autoriser la demande d’introspection. | ||
Pour un serveur de ressource, cela est plus compliqué du fait de la durée limitée de validité du jeton d’accès, contraignant à une nouvelle demande de jeton. Une façon d’obtenir un tel jeton consiste à inscrire l’application pour le flux Client Credential Grant. | Pour un serveur de ressource, cela est plus compliqué du fait de la durée limitée de validité du jeton d’accès, contraignant à une nouvelle demande de jeton. Une façon d’obtenir un tel jeton consiste à inscrire l’application pour le flux Client Credential Grant. | ||
| Ligne 339 : | Ligne 341 : | ||
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> | </pre> | ||
https://dev.to/gbtux/authentification-openid-connect-avec-symfony-3m5h | https://dev.to/gbtux/authentification-openid-connect-avec-symfony-3m5h<br /> | ||
le provider | le provider fournit un JWT. | ||
<pre> | <pre> | ||
security.yaml | security.yaml | ||
| Ligne 369 : | Ligne 371 : | ||
[https://oa.dnc.global/-Decouvrir-.html#definitions Définitions]<br /> | [https://oa.dnc.global/-Decouvrir-.html#definitions Définitions]<br /> | ||
[https://oa.dnc.global/-OAuth-2-0-.html#oauth20lestypesdautorisationgranttype OAuth 2.0 : Les Types d’Autorisation (Grant Type)] | [https://oa.dnc.global/-OAuth-2-0-.html#oauth20lestypesdautorisationgranttype OAuth 2.0 : Les Types d’Autorisation (Grant Type)] | ||
[https://oauth2.thephpleague.com/authorization-server/which-grant/ PHP OAuth 2.0 authorization server] | |||
[[Catégorie:Oauth2]] | [[Catégorie:Oauth2]] | ||