« Oauth2 lecture » : différence entre les versions

(5 versions intermédiaires par le même utilisateur non affichées)

Ligne 23 :

</pre>

https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir

=== OAuth2 et OpenID Connect ===

Ligne 36 :

Ligne 35 :

=== Authentifier l’application ===

~~[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]~~

<pre>

Le serveur de ressource (Resource Server) doit pouvoir vérifier la légitimité du détenteur du token.

Ligne 49 :

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."

</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 ===

Ligne 83 :

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 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>

Ligne 254 :

Ligne 253 :

=== Forme de la demande d’Introspection ===

'''Contrôle de l’accès'''

<pre>

~~Contrôle de l’accès~~

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

</pre>

Client Credentials Grant

'''Client Credentials Grant'''

<pre>

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’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.

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 340 :

Ligne 341 :

Autoriser: OK l'utilisateur existe, il s'est authentifié, mais a-t-il le droit d'accéder à l'application ?

</pre>

https://dev.to/gbtux/authentification-openid-connect-avec-symfony-3m5h~~#:~:text=Mais%20en%20fait%20la%20brique,%2C%20etc.....~~

https://dev.to/gbtux/authentification-openid-connect-avec-symfony-3m5h<br />

le provider ~~c'est ce qui est retourné par L'AS,~~ un JWT

le provider fournit un JWT.

<pre>

security.yaml

Ligne 370 :

Ligne 371 :

[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://oauth2.thephpleague.com/authorization-server/which-grant/ PHP OAuth 2.0 authorization server]

[[Catégorie:Oauth2]]

@@ Ligne 23 : / Ligne 23 : @@
 </pre>
 https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir
 === OAuth2 et OpenID Connect ===
@@ Ligne 36 : / Ligne 35 : @@
 === Authentifier l’application ===
-[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]
 <pre>
 Le serveur de ressource (Resource Server) doit pouvoir vérifier la légitimité du détenteur du token.
@@ Ligne 49 : / 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."
 </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 ===
@@ Ligne 83 : / 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 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>
@@ Ligne 254 : / Ligne 253 : @@
 === Forme de la demande d’Introspection ===
+'''Contrôle de l’accès'''
 <pre>
-Contrôle de l’accès
 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
+</pre>
-Client Credentials Grant
+'''Client Credentials Grant'''
+<pre>
 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’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.
 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 340 : / Ligne 341 : @@
 Autoriser: OK l'utilisateur existe, il s'est authentifié, mais a-t-il le droit d'accéder à l'application ?
 </pre>
-https://dev.to/gbtux/authentification-openid-connect-avec-symfony-3m5h#:~:text=Mais%20en%20fait%20la%20brique,%2C%20etc.....
+https://dev.to/gbtux/authentification-openid-connect-avec-symfony-3m5h<br />
-le provider c'est ce qui est retourné par L'AS, un JWT
+le provider fournit un JWT.
 <pre>
 security.yaml
@@ Ligne 370 : / Ligne 371 : @@
 [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://oauth2.thephpleague.com/authorization-server/which-grant/ PHP OAuth 2.0 authorization server]
 [[Catégorie:Oauth2]]

« Oauth2 lecture » : différence entre les versions

« Oauth2 lecture » : différence entre les versions