Marmits Wiki

« Oauth2 lecture » : différence entre les versions

← Modification précédente
Aucun résumé des modifications
 
(23 versions intermédiaires par le même utilisateur non affichées)
Ligne 1 : Ligne 1 :
(à réorganiser)
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 8 : Ligne 9 :
Client = Relying Party
Client = Relying Party


=== vocabulaire ===
<pre>
<pre>
-Le Resource Provider expose des ressources, publiques ou privées, sur le Web via une API REST bien designée. Cher lecteur, il s’agit probablement de votre produit !
-Le Développeur veut utiliser ces ressources afin de fournir un nouveau service via son application.
-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.
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 15 : Ligne 22 :
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
=== OAuth2 et OpenID Connect ===
<pre>
Les standards de l’industrie pour l’authentification et l’autorisation sont OAuth2 et OpenID Connect : OAuth2 est dédié à la délégation de droits (“moi, utilisateur, autorise cette application à lire mes mails en mon nom”) et OIDC, à la gestion d’identités.
Ces deux protocoles couvrent à eux deux 99,9% des cas possibles. Nous vous DÉCONSEILLONS FORTEMENT d’essayer d’utiliser d’autres protocoles ou d’essayer de réinventer la roue, ce serait un frein inutile ajouté à vos clients que sont les développeurs d’applications.
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>
https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir
=== Authentifier l’application ===
<pre>
Le serveur de ressource (Resource Server) doit pouvoir vérifier la légitimité du détenteur du token.
Mais comment ?
La spécification décrit clairement cette limitation (§10.3) :
Cette spécification ne fournit aucune méthode pour que le serveur de ressources s’assure qu’un jeton d’accès qui lui est présenté par un client donné a été émis pour ce client par le serveur d’autorisation.
"vous pouvez utiliser les jetons d’accès JWT si vous avez des systèmes distribués et que vous devez valider l’authenticité d’un jeton auprès de plusieurs parties sans avoir à passer un appel réseau.
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 ===
=== OAuth 2.0 est un système d’autorisation ===
Ligne 49 : 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>
 
=== 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).
</pre>
 
=== code d'autorisation ===
<pre>
Le code d'autorisation est obtenu en utilisant un serveur d'autorisation
en tant qu'intermédiaire entre le client et le propriétaire de la ressource. Au lieu de
demander l'autorisation directement au propriétaire de la ressource, le client
dirige le propriétaire de la ressource vers un serveur d'autorisation (via son
user-agent tel que défini dans [RFC2616]), qui à son tour dirige le
propriétaire de la ressource au client avec le code d'autorisation.
 
Avant de rediriger le propriétaire de la ressource vers le client avec le
code d'autorisation, le serveur d'autorisation authentifie le
propriétaire de la ressource et obtient l'autorisation. Parce que le propriétaire de la ressource
s'authentifie uniquement auprès du serveur d'autorisation, la ressource
les informations d'identification du propriétaire ne sont jamais partagées avec le client.
 
Le code d'autorisation offre quelques avantages de sécurité importants,
telles que la possibilité d'authentifier le client, ainsi que la
transmission du jeton d'accès directement au client sans
en le faisant passer par l'agent utilisateur du propriétaire de la ressource et éventuellement
l'exposer à d'autres, y compris le propriétaire de la ressource.
 
Le serveur de ressources est le terme OAuth 2.0 pour votre serveur d'API. Le serveur de ressources gère les demandes authentifiées une fois que l'application a obtenu un jeton d'accès.
 
Les déploiements à grande échelle peuvent avoir plusieurs serveurs de ressources. Les services de Google, par exemple, disposent de dizaines de serveurs de ressources, tels que la plateforme Google Cloud, Google Maps, Google Drive, Youtube, Google+ et bien d'autres. Chacun de ces serveurs de ressources est distinct, mais ils partagent tous le même serveur d'autorisation.
</pre>
</pre>


=== Jeton d'identification ===  
=== Jeton d'identification ===  
google exemple
[https://developers.google.com/identity/protocols/oauth2/openid-connect?csw=1#validatinganidtoken google exemple]
[https://developers.google.com/identity/protocols/oauth2/openid-connect?csw=1#validatinganidtoken google exemple]
<pre>
<pre>
jeton d’identité (ID Token) fondé sur JWT.
La validation d'un jeton d'identification nécessite plusieurs étapes :
La validation d'un jeton d'identification nécessite plusieurs étapes :


Ligne 61 : Ligne 135 :
Vérifiez  la valeur de la revendication iss dans le jeton d'ID  
Vérifiez  la valeur de la revendication iss dans le jeton d'ID  
Vérifiez que la valeur de la revendication aud dans le jeton d'ID est égale à l'ID client de votre application.
Vérifiez que la valeur de la revendication aud dans le jeton d'ID est égale à l'ID client de votre application.
Vérifiez que le délai d'expiration (demande exp ) du jeton d'ID n'est pas dépassé.
Vérifiez que le délai d'expiration (demande exp) du jeton d'ID n'est pas dépassé.
Si vous avez spécifié une valeur de paramètre hd dans la demande, vérifiez que le jeton d'ID a une revendication hd qui correspond à un domaine hébergé accepté.
Si vous avez spécifié une valeur de paramètre hd dans la demande, vérifiez que le jeton d'ID a une revendication hd qui correspond à un domaine hébergé accepté.


les clefs publiques peuvent etre mises en cache et donc effectuer une validation local.
les clefs publiques peuvent etre mises en cache et donc effectuer une validation local.
Cette validation nécessite de récupérer et d'analyser les certificats, et d'effectuer les appels cryptographiques appropriés pour vérifier la signature
Cette validation nécessite de récupérer et d'analyser les certificats, et d'effectuer les appels cryptographiques appropriés pour vérifier la signature
Heureusement, il existe des bibliothèques bien déboguées disponibles dans une grande variété de langages pour accomplir cela (voir jwt.io ).
Heureusement, il existe des bibliothèques bien déboguées disponibles dans une grande variété de langages pour accomplir cela
</pre>
</pre>
[https://jwt.io/ (voir jwt.io)]


=== JWT ===
=== ID Token ===
<pre>
<pre>
Ils permettent à un fournisseur d’API de vérifier l’identité d’un utilisateur et les droits d’un client, à la réception d’une requête, sans nécessiter un appel au Serveur d’Autorisation.  
Ils permettent à un fournisseur d’API de vérifier l’identité d’un utilisateur et les droits d’un client, à la réception d’une requête, sans nécessiter un appel au Serveur d’Autorisation.  
Ligne 84 : Ligne 159 :


D’autres claims sont optionnels et peuvent être retournés par le Serveur d’Identités si ils ont été demandés par le client. Il s’agit souvent d’informations sur l’utilisateur : par exemple son nom, son email, sa date de naissance… La spécification OIDC précise la syntaxe de beaucoup de claims standards (given_name, gender, birthdate…)  
D’autres claims sont optionnels et peuvent être retournés par le Serveur d’Identités si ils ont été demandés par le client. Il s’agit souvent d’informations sur l’utilisateur : par exemple son nom, son email, sa date de naissance… La spécification OIDC précise la syntaxe de beaucoup de claims standards (given_name, gender, birthdate…)  
</pre>


###########################
=== JWT ===
<pre>
Les jetons JWT sont des jetons compacts et légers conçus pour être transmis dans les en-têtes HTTP et les paramètres de requête. Ils sont signés pour protéger l'intégrité de ses données et peuvent même être cryptés pour des raisons de confidentialité. Comme le format est bien défini, le serveur de ressources peut décoder et vérifier le jeton sans appeler d'autre système.
 
Les jetons structurés sont des jetons passés par valeur. Le jeton contient suffisamment de données pour que le serveur de ressources prenne sa décision d'autorisation. Souvent, il contient également des informations sur l'utilisateur. Dans certains cas, un tel jeton peut même contenir des informations personnelles identifiables (PII) ou d'autres données protégées par la loi ou la réglementation et le jeton ainsi que les systèmes connexes deviennent soumis à des exigences de conformité.


le jeton d’identité JWT regroupe, de façon indissociable et infalsifiable, l’identité de l’utilisateur final, celle de l’application cliente et les portées d’autorisation
le jeton d’identité JWT regroupe, de façon indissociable et infalsifiable, l’identité de l’utilisateur final, celle de l’application cliente et les portées d’autorisation
Ligne 131 : Ligne 211 :
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 159 : Ligne 238 :
Les identifiants de jeton d’accès (ainsi que tous les attributs de jeton d’accès confidentiels) DOIVENT être gardés confidentiels pendant le transit et le stockage, et partagés uniquement entre le serveur d’autorisation, les serveurs de ressources pour lesquels le jeton d’accès est valide et le client auquel le jeton d’accès est émis.
Les identifiants de jeton d’accès (ainsi que tous les attributs de jeton d’accès confidentiels) DOIVENT être gardés confidentiels pendant le transit et le stockage, et partagés uniquement entre le serveur d’autorisation, les serveurs de ressources pour lesquels le jeton d’accès est valide et le client auquel le jeton d’accès est émis.
</pre>
</pre>
https://oa.dnc.global/-Sujets-communs-a-Oauth-2-et-OpenID-Connect-.html#definitiondesscopesoidcetgeneralitessurleurutilisationparlesapplications
[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]


=== INTROSPECTION ===
=== Introspection ===
<pre>
<pre>
L’introspection permet à une application cliente OU à un serveur de ressource (RS) de valider un jeton auprès du serveur d’authentification (AS) .
L’introspection permet à une application cliente OU à un serveur de ressource (RS) de valider un jeton auprès du serveur d’authentification (AS) .
Ligne 170 : Ligne 249 :
- 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>
https://oa.dnc.global/-Authentifier-l-application-.html#verificationdeloriginedelarequeterecueparunserveurderessource
extremite=>"introspect"<br />
https://oa.dnc.global/-API-OpenID-Connect-Points-d-extremite-.html#apiopenidconnectintrospectionintrospectionendpoint


extremite=>"introspect"
=== Forme de la demande d’Introspection ===
https://oa.dnc.global/-API-OpenID-Connect-Points-d-extremite-.html#apiopenidconnectintrospectionintrospectionendpoint
'''Contrôle de l’accès'''
<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).
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'''
<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'''
<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.
L’authentification est effectuée en passant le jeton dans l’en-tête Authorization de la demande d’introspection.
</pre>


=== Contrôle de l’accès ===
=== Contrôle de l’accès ===
Ligne 219 : Ligne 315 :
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/-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>
 


=== Problématique ===
=== Problématique ===
Ligne 252 : Ligne 332 :
Les clients DOIVENT valider le jeton ID dans la réponse au jeton de la manière suivante :
Les clients DOIVENT valider le jeton ID dans la réponse au jeton de la manière suivante :
</pre>
</pre>
https://oa.dnc.global/-OpenID-Connect-6-.html#validationdujetondidentiteidtokenjwtsigneoujws
[https://oa.dnc.global/-OpenID-Connect-6-.html#validationdujetondidentiteidtokenjwtsigneoujws Validation du jeton d’identité ID Token (JWT signé ou JWS)]
<pre>
Les jetons JWT sont des jetons compacts et légers conçus pour être transmis dans les en-têtes HTTP et les paramètres de requête. Ils sont signés pour protéger l'intégrité de ses données et peuvent même être cryptés pour des raisons de confidentialité. Comme le format est bien défini, le serveur de ressources peut décoder et vérifier le jeton sans appeler d'autre système.


Les jetons structurés sont des jetons passés par valeur. Le jeton contient suffisamment de données pour que le serveur de ressources prenne sa décision d'autorisation. Souvent, il contient également des informations sur l'utilisateur. Dans certains cas, un tel jeton peut même contenir des informations personnelles identifiables (PII) ou d'autres données protégées par la loi ou la réglementation et le jeton ainsi que les systèmes connexes deviennent soumis à des exigences de conformité.
=== Symfony ===
</pre>
La brique "d'authentification" a 3 rôles
 
 
=== vocabulaire ===
<pre>
-Le Resource Provider expose des ressources, publiques ou privées, sur le Web via une API REST bien designée. Cher lecteur, il s’agit probablement de votre produit !
-Le Développeur veut utiliser ces ressources afin de fournir un nouveau service via son application.
-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.
</pre>
 
=== la brique "d'authentification" a 3 rôles ===
<pre>
<pre>
fournisseur d'identité : qui est l'utilisateur ? ses informations ? Nom, prénom, username, etc.....
fournisseur d'identité : qui est l'utilisateur ? ses informations ? Nom, prénom, username, etc.....
Ligne 274 : 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<br />
=== code d'autorisation ===
le provider fournit un JWT.
<pre>
Le code d'autorisation est obtenu en utilisant un serveur d'autorisation
en tant qu'intermédiaire entre le client et le propriétaire de la ressource. Au lieu de
demander l'autorisation directement au propriétaire de la ressource, le client
dirige le propriétaire de la ressource vers un serveur d'autorisation (via son
user-agent tel que défini dans [RFC2616]), qui à son tour dirige le
propriétaire de la ressource au client avec le code d'autorisation.
 
Avant de rediriger le propriétaire de la ressource vers le client avec le
code d'autorisation, le serveur d'autorisation authentifie le
propriétaire de la ressource et obtient l'autorisation. Parce que le propriétaire de la ressource
s'authentifie uniquement auprès du serveur d'autorisation, la ressource
les informations d'identification du propriétaire ne sont jamais partagées avec le client.
 
Le code d'autorisation offre quelques avantages de sécurité importants,
telles que la possibilité d'authentifier le client, ainsi que la
transmission du jeton d'accès directement au client sans
en le faisant passer par l'agent utilisateur du propriétaire de la ressource et éventuellement
l'exposer à d'autres, y compris le propriétaire de la ressource.
 
Le serveur de ressources est le terme OAuth 2.0 pour votre serveur d'API. Le serveur de ressources gère les demandes authentifiées une fois que l'application a obtenu un jeton d'accès.
 
Les déploiements à grande échelle peuvent avoir plusieurs serveurs de ressources. Les services de Google, par exemple, disposent de dizaines de serveurs de ressources, tels que la plateforme Google Cloud, Google Maps, Google Drive, Youtube, Google+ et bien d'autres. Chacun de ces serveurs de ressources est distinct, mais ils partagent tous le même serveur d'autorisation.
</pre>
 
=== 2022-04-25 ===
https://www.mechantblog.com/2018/12/token-api-macaroon-jwt/
<pre>
Vu que le secret peut être asymétrique, Il est possible de créer une clé privée/publique par utilisateur. On génère un token avec la clé privée, et on enregistre la clé publique dans la base de données. Cette clé n’est pas critique et peut être volée sans rien compromettre. Ce qui donnerait ceci:
Récupération du token dans le header (ou un cookie, une session, etc…)
Extraction du champs userId dans le payload
Récupération de la clé publique liée à cet utilisateur
Vérification du token avec la clé publique
Si c’est bon, le token est confirmé et on peut faire confiance aux infos du payload
 
RS256 utilise le cryptage à clé publique pour signer le jeton. La signature (hachage) sera créée à l'aide de la clé privée et pourra être vérifiée à l'aide de la clé publique. Ainsi, pas besoin de clé privée ou de secret client à stocker sur le serveur principal, mais le serveur principal récupère la clé publique à partir de l'URL de configuration openid de votre locataire (https://[tenant]/.well-known/openid -configuration) pour vérifier le jeton. Le paramètre KID à l'intérieur de access_toekn sera utilisé pour détecter la bonne clé (publique) à partir de la configuration openid.
</pre>
 
=== 2022-04-26 ===
<pre>
Le serveur de ressource (Resource Server) doit pouvoir vérifier la légitimité du détenteur du token.
 
Mais comment ?
 
La spécification décrit clairement cette limitation (§10.3) :
 
Cette spécification ne fournit aucune méthode pour que le serveur de ressources s’assure qu’un jeton d’accès qui lui est présenté par un client donné a été émis pour ce client par le serveur d’autorisation.
 
"vous pouvez utiliser les jetons d’accès JWT si vous avez des systèmes distribués et que vous devez valider l’authenticité d’un jeton auprès de plusieurs parties sans avoir à passer un appel réseau.
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>
 
=== 2022-04-28 ===
https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir/#security_pillars
 
=== OAuth2 et OpenID Connect ===
<pre>
Les standards de l’industrie pour l’authentification et l’autorisation sont OAuth2 et OpenID Connect : OAuth2 est dédié à la délégation de droits (“moi, utilisateur, autorise cette application à lire mes mails en mon nom”) et OIDC, à la gestion d’identités.
 
Ces deux protocoles couvrent à eux deux 99,9% des cas possibles. Nous vous DÉCONSEILLONS FORTEMENT d’essayer d’utiliser d’autres protocoles ou d’essayer de réinventer la roue, ce serait un frein inutile ajouté à vos clients que sont les développeurs d’applications.
 
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>
 
 
=== Symfony ===
le provider c'est ce qui est retourné par L'AS, un JWT
<pre>
<pre>
security.yaml
security.yaml
Ligne 364 : Ligne 364 :
         - { path: ^/api, roles: IS_AUTHENTICATED_FULLY }
         - { path: ^/api, roles: IS_AUTHENTICATED_FULLY }
</pre>
</pre>
=== Ressources ===
[https://www.mechantblog.com/2018/12/token-api-macaroon-jwt/ Le TOKEN API: Simple, JWT et macaron]<br />
[https://blog.octo.com/securiser-une-api-rest-tout-ce-quil-faut-savoir#security_pillars Sécuriser une API REST : tout ce qu’il faut savoir]<br />
[https://www.vaadata.com/blog/fr/jetons-jwt-et-securite-principes-et-cas-dutilisation/ Jetons JWT et sécurité – Principes et cas d’utilisation]<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://oauth2.thephpleague.com/authorization-server/which-grant/ PHP OAuth 2.0 authorization server]


[[Catégorie:Oauth2]]
[[Catégorie:Oauth2]]
Récupérée de "https://marmits.com/wiki/Oauth2_lecture"