« Oauth2 lecture » : différence entre les versions
Aucun résumé des modifications |
|||
| (6 versions intermédiaires par le même utilisateur non affichées) | |||
| Ligne 1 : | Ligne 1 : | ||
Résumé de lecture de https://oa.dnc.global/-fr-.html | Résumé de lecture de :<br /> | ||
https://oa.dnc.global/-fr-.html et de https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir | |||
=== Serveur === | === Serveur === | ||
| Ligne 22 : | Ligne 23 : | ||
</pre> | </pre> | ||
https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir | https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir | ||
=== OAuth2 et OpenID Connect === | === OAuth2 et OpenID Connect === | ||
| Ligne 35 : | Ligne 35 : | ||
=== Authentifier l’application === | === Authentifier l’application === | ||
<pre> | <pre> | ||
Le serveur de ressource (Resource Server) doit pouvoir vérifier la légitimité du détenteur du token. | Le serveur de ressource (Resource Server) doit pouvoir vérifier la légitimité du détenteur du token. | ||
| Ligne 48 : | Ligne 47 : | ||
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." | 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> | ||
[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] | |||
=== OAuth 2.0 est un système d’autorisation === | === OAuth 2.0 est un système d’autorisation === | ||
| 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]] | ||