Marmits Wiki

« Oauth2 lecture » : différence entre les versions

← Modification précédenteModification suivante →
Aucun résumé des modifications
Aucun résumé des modifications
Ligne 17 : Ligne 17 :


=== JWT ===
=== JWT ===
<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 22 : Ligne 23 :


Alors qu’en utilisant JWT, votre API peut elle-même valider le token grâce à la signature, et récupérer les informations de l’utilisateur incluses dans le payload. Cela lui permet d’économiser bien des appels, et éviter au Serveur d’Autorisation d’avoir à supporter une charge trop lourde, d’autant plus que certaines solutions en SaaS (comme Auth0 par exemple) imposent des quotas sur ce type de requête.
Alors qu’en utilisant JWT, votre API peut elle-même valider le token grâce à la signature, et récupérer les informations de l’utilisateur incluses dans le payload. Cela lui permet d’économiser bien des appels, et éviter au Serveur d’Autorisation d’avoir à supporter une charge trop lourde, d’autant plus que certaines solutions en SaaS (comme Auth0 par exemple) imposent des quotas sur ce type de requête.
</pre>
 
=== scope openid ===
<pre>
ID Token =
Contrairement à l’access token qui a vocation à être utilisé par le client pour s’authentifier auprès du serveur de ressources (et donc être partagé au serveur de ressources), l’ID Token n’est à destination que du client, et ne devrait jamais être envoyé au serveur de ressources.  
Contrairement à l’access token qui a vocation à être utilisé par le client pour s’authentifier auprès du serveur de ressources (et donc être partagé au serveur de ressources), l’ID Token n’est à destination que du client, et ne devrait jamais être envoyé au serveur de ressources.  


Ligne 52 : Ligne 50 :


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.
###########################
https://curity.io/resources/learn/jwt-best-practices/
<pre>
le Serveur d’Autorisation appose une signature digitale à ses tokens, de sorte que le fournisseur d’API puisse vérifier la signature, et ainsi être assuré que le token a été émis par une autorité de confiance.
Dans le cas d'un JWT signé - un JWS - vous devez vous rappeler que la signature est utilisée pour signer non seulement la charge utile du jeton, mais également l'en-tête. Toute modification de l'en-tête ou de la charge utile générerait une signature différente. Cela ne doit même pas nécessairement être un changement dans les valeurs des revendications - l'ajout ou la suppression d'espaces ou de sauts de ligne créera également une signature de jeton différente.
Il convient de noter que pour atténuer une situation où deux jetons seraient créés avec exactement la même signature (donc deux jetons créés dans la même seconde, pour le même client et utilisateur, avec la même portée, etc.) de nombreux serveurs d'autorisation ajoutez un ID aléatoire du jeton dans la revendication jti. Grâce à cela, vous pouvez être sûr que deux jetons différents n'auront jamais la même signature.
Les signatures nécessitent des clés ou des certificats pour être correctement validées. Ces clés ou certificats peuvent être obtenus auprès du serveur d'autorisation de différentes manières. Vous pouvez, par ex. obtenez les clés de l'AS dans un processus d'intégration et assurez-vous que tous vos serveurs de ressources ont accès à ces clés. Cela crée cependant un problème lorsque les clés ou les certificats changent. C'est pourquoi il est recommandé de toujours utiliser un point de terminaison et de télécharger dynamiquement les clés ou les certificats à partir du serveur d'autorisation (mise en cache des réponses en fonction de ce que le serveur renvoie dans les en-têtes de contrôle du cache). Cela permet une rotation facile des clés, et une telle rotation ne cassera pas votre implémentation.
Si les clés ou les certificats sont envoyés dans l'en-tête du JWT, vous devez toujours les comparer à une liste blanche de clés ou valider la chaîne de confiance en cas de certificats.
Rappelez-vous également que l'alg dans l'en-tête doit être sur liste blanche (comme expliqué ici et vous devez vérifier si l'émetteur est le propriétaire des clés / certificats.
11. Utiliser les jeux de clés Web JSON pour la distribution des clés
Pour vérifier l'intégrité d'un JWT, une API doit accéder à une clé publique. Vous pouvez y parvenir de plusieurs manières : vous pouvez coder en dur la valeur de la clé ou interroger un point de terminaison au démarrage de votre service et mettre en cache le résultat.
La méthode recommandée consiste à obtenir une clé à partir d'un point de terminaison JWKS exposé par le serveur OAuth. L'API doit mettre en cache la clé téléchargée pour limiter le trafic inutile, mais doit interroger à nouveau le point de terminaison JWKS chaque fois qu'elle trouve une clé de signature qu'elle ne connaît pas.
Cela permet une simple rotation des clés, que le serveur OAuth peut gérer à la demande sans entraver les services API. L'utilisation de jeux de clés au lieu de clés permet également une rotation transparente des clés pour les clients. Le serveur OAuth peut commencer à émettre de nouveaux jetons signés avec une nouvelle clé et valider les jetons existants tant que l'ancienne clé publique fait partie de l'ensemble de clés.
13. Gérer les CLAIMS de manière centralisée
Comme défini par la spécification JWT, une revendication est une information affirmée sur un sujet. Il est recommandé de faire valoir ces revendications par un serveur OAuth centralisé, ce qui facilite le contrôle des revendications qui apparaissent dans vos jetons. Ceci est important pour des raisons de confidentialité et de sécurité.
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>
</pre>
=== OAuth 2.0 est un système d’autorisation ===
=== OAuth 2.0 est un système d’autorisation ===
Ligne 310 : Ligne 337 :
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>
=== JWT ===
https://curity.io/resources/learn/jwt-best-practices/
<pre>
le Serveur d’Autorisation appose une signature digitale à ses tokens, de sorte que le fournisseur d’API puisse vérifier la signature, et ainsi être assuré que le token a été émis par une autorité de confiance.


Dans le cas d'un JWT signé - un JWS - vous devez vous rappeler que la signature est utilisée pour signer non seulement la charge utile du jeton, mais également l'en-tête. Toute modification de l'en-tête ou de la charge utile générerait une signature différente. Cela ne doit même pas nécessairement être un changement dans les valeurs des revendications - l'ajout ou la suppression d'espaces ou de sauts de ligne créera également une signature de jeton différente.
Il convient de noter que pour atténuer une situation où deux jetons seraient créés avec exactement la même signature (donc deux jetons créés dans la même seconde, pour le même client et utilisateur, avec la même portée, etc.) de nombreux serveurs d'autorisation ajoutez un ID aléatoire du jeton dans la revendication jti. Grâce à cela, vous pouvez être sûr que deux jetons différents n'auront jamais la même signature.
Les signatures nécessitent des clés ou des certificats pour être correctement validées. Ces clés ou certificats peuvent être obtenus auprès du serveur d'autorisation de différentes manières. Vous pouvez, par ex. obtenez les clés de l'AS dans un processus d'intégration et assurez-vous que tous vos serveurs de ressources ont accès à ces clés. Cela crée cependant un problème lorsque les clés ou les certificats changent. C'est pourquoi il est recommandé de toujours utiliser un point de terminaison et de télécharger dynamiquement les clés ou les certificats à partir du serveur d'autorisation (mise en cache des réponses en fonction de ce que le serveur renvoie dans les en-têtes de contrôle du cache). Cela permet une rotation facile des clés, et une telle rotation ne cassera pas votre implémentation.
Si les clés ou les certificats sont envoyés dans l'en-tête du JWT, vous devez toujours les comparer à une liste blanche de clés ou valider la chaîne de confiance en cas de certificats.
Rappelez-vous également que l'alg dans l'en-tête doit être sur liste blanche (comme expliqué ici et vous devez vérifier si l'émetteur est le propriétaire des clés / certificats.
11. Utiliser les jeux de clés Web JSON pour la distribution des clés
Pour vérifier l'intégrité d'un JWT, une API doit accéder à une clé publique. Vous pouvez y parvenir de plusieurs manières : vous pouvez coder en dur la valeur de la clé ou interroger un point de terminaison au démarrage de votre service et mettre en cache le résultat.
La méthode recommandée consiste à obtenir une clé à partir d'un point de terminaison JWKS exposé par le serveur OAuth. L'API doit mettre en cache la clé téléchargée pour limiter le trafic inutile, mais doit interroger à nouveau le point de terminaison JWKS chaque fois qu'elle trouve une clé de signature qu'elle ne connaît pas.
Cela permet une simple rotation des clés, que le serveur OAuth peut gérer à la demande sans entraver les services API. L'utilisation de jeux de clés au lieu de clés permet également une rotation transparente des clés pour les clients. Le serveur OAuth peut commencer à émettre de nouveaux jetons signés avec une nouvelle clé et valider les jetons existants tant que l'ancienne clé publique fait partie de l'ensemble de clés.
13. Gérer les CLAIMS de manière centralisée
Comme défini par la spécification JWT, une revendication est une information affirmée sur un sujet. Il est recommandé de faire valoir ces revendications par un serveur OAuth centralisé, ce qui facilite le contrôle des revendications qui apparaissent dans vos jetons. Ceci est important pour des raisons de confidentialité et de sécurité.
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>


=== Symfony ===
=== Symfony ===
Récupérée de "https://marmits.com/wiki/Oauth2_lecture"