Oauth2 lecture - Historique des versions

Geo : /* Forme de la demande d’Introspection */

2024-05-23T14:12:00Z

Forme de la demande d’Introspection

← Version précédente		Version du 23 mai 2024 à 16:12
Ligne 253 :		Ligne 253 :

	=== Forme de la demande d’Introspection ===		=== Forme de la demande d’Introspection ===
			'''Contrôle de l’accès'''
	<pre>		<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).		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.

Geo : /* Forme de la demande d’Introspection */

2024-05-23T14:10:11Z

Forme de la demande d’Introspection

← Version précédente		Version du 23 mai 2024 à 16:10
Ligne 254 :		Ligne 254 :
	=== Forme de la demande d’Introspection ===		=== Forme de la demande d’Introspection ===
	<pre>		<pre>
	Contrôle de l’accès		'''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).		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

	Client Credentials Grant		'''Client Credentials Grant'''
	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.

	Bearer Token		'''Bearer Token'''
	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.

Geo le 23 mai 2024 à 13:44

2024-05-23T13:44:34Z

← Version précédente		Version du 23 mai 2024 à 15:44
Ligne 340 :		Ligne 340 :
	</pre>		</pre>
	https://dev.to/gbtux/authentification-openid-connect-avec-symfony-3m5h<br />		https://dev.to/gbtux/authentification-openid-connect-avec-symfony-3m5h<br />
	le provider un JWT		le provider fournit un JWT.
	<pre>		<pre>
	security.yaml		security.yaml

Geo le 23 mai 2024 à 13:43

2024-05-23T13:43:28Z

← Version précédente		Version du 23 mai 2024 à 15:43
Ligne 369 :		Ligne 369 :
	[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]]

Geo le 23 mai 2024 à 13:41

2024-05-23T13:41:10Z

← Version précédente		Version du 23 mai 2024 à 15:41
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 339 :		Ligne 339 :
	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~~#:~: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 un JWT
	<pre>		<pre>
	security.yaml		security.yaml

Geo le 23 mai 2024 à 13:26

2024-05-23T13:26:28Z

← Version précédente		Version du 23 mai 2024 à 15:26
Ligne 23 :		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 36 :		Ligne 35 :

	=== Authentifier l’application ===		=== 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>		<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 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."		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 ===

Geo le 23 mai 2024 à 13:22

2024-05-23T13:22:59Z

← Version précédente		Version du 23 mai 2024 à 15:22
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 ===

Geo le 23 mai 2024 à 13:22

2024-05-23T13:22:11Z

← Version précédente		Version du 23 mai 2024 à 15:22
Ligne 32 :		Ligne 32 :
	Vous pouvez vous contenter d’utiliser OAuth2 si vous êtes à la fois resource provider et identity provider (et rappelez-vous que vous l’êtes sûrement). OpenID Connect est une extension du protocole OAuth2 et vous permettra donc une migration sans douleur si vous décidez d’utiliser un identity provider externe (connexion avec Facebook, Linkedin, Google, etc).		Vous pouvez vous contenter d’utiliser OAuth2 si vous êtes à la fois resource provider et identity provider (et rappelez-vous que vous l’êtes sûrement). OpenID Connect est une extension du protocole OAuth2 et vous permettra donc une migration sans douleur si vous décidez d’utiliser un identity provider externe (connexion avec Facebook, Linkedin, Google, etc).
	</pre>		</pre>
			https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir

	=== Authentifier l’application ===		=== Authentifier l’application ===

Geo le 23 mai 2024 à 13:18

2024-05-23T13:18:58Z

← Version précédente		Version du 23 mai 2024 à 15:18
Ligne 21 :		Ligne 21 :
	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>		</pre>
			https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir

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

	=== OAuth2 et OpenID Connect ===		=== OAuth2 et OpenID Connect ===
Ligne 337 :		Ligne 332 :

	=== Symfony ===		=== Symfony ===
			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>
			https://dev.to/gbtux/authentification-openid-connect-avec-symfony-3m5h#:~:text=Mais%20en%20fait%20la%20brique,%2C%20etc.....
	le provider c'est ce qui est retourné par L'AS, un JWT		le provider c'est ce qui est retourné par L'AS, un JWT
	<pre>		<pre>

Geo le 23 mai 2024 à 13:10

2024-05-23T13:10:45Z

← Version précédente		Version du 23 mai 2024 à 15:10
Ligne 14 :		Ligne 14 :
	-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’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.		-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>~~
	Le serveur d'autorisation gère l'autorisation et la gestion des jetons.		Le serveur d'autorisation gère l'autorisation et la gestion des jetons.

Ligne 39 :		Ligne 37 :
	Vous pouvez vous contenter d’utiliser OAuth2 si vous êtes à la fois resource provider et identity provider (et rappelez-vous que vous l’êtes sûrement). OpenID Connect est une extension du protocole OAuth2 et vous permettra donc une migration sans douleur si vous décidez d’utiliser un identity provider externe (connexion avec Facebook, Linkedin, Google, etc).		Vous pouvez vous contenter d’utiliser OAuth2 si vous êtes à la fois resource provider et identity provider (et rappelez-vous que vous l’êtes sûrement). OpenID Connect est une extension du protocole OAuth2 et vous permettra donc une migration sans douleur si vous décidez d’utiliser un identity provider externe (connexion avec Facebook, Linkedin, Google, etc).
	</pre>		</pre>


	=== Authentifier l’application ===		=== Authentifier l’application ===
Ligne 150 :		Ligne 147 :
	</pre>		</pre>
	[https://jwt.io/ (voir jwt.io)]		[https://jwt.io/ (voir jwt.io)]



	=== ID Token ===		=== ID Token ===

Oauth2 lecture - Historique des versions

Geo : /* Forme de la demande d’Introspection */

Geo : /* Forme de la demande d’Introspection */

Geo le 23 mai 2024 à 13:44

Geo le 23 mai 2024 à 13:43

Geo le 23 mai 2024 à 13:41

Geo le 23 mai 2024 à 13:26

Geo le 23 mai 2024 à 13:22

Geo le 23 mai 2024 à 13:22

Geo le 23 mai 2024 à 13:18

Geo le 23 mai 2024 à 13:10

Geo : /* Forme de la demande d’Introspection */

Geo : /* Forme de la demande d’Introspection */