Amazoncognito com oauth2 token

par Prashob Krishnan, Ishva Kanani et Keerthana Ganeshon dans Amazon Cognito, Bonnes pratiques, Intermédiaire (200), Sécurité, Identité et conformitéCommentaires sur les liens maliens Partager

La mise en œuvre de mécanismes d’authentification et d’autorisation dans les applications modernes peut s’avérer difficile, en particulier lorsqu’il s’agit de différents types de clients et de cas d’utilisation. En tant que développeurs, nous avons souvent du mal à choisir le bon flux d’authentification pour équilibrer la sécurité, l’expérience utilisateur et les exigences de l’application. C’est là que la compréhension des types d’octroi OAuth 2.0 entre en jeu. Que vous créiez une application web traditionnelle, une application mobile ou un système de communication de machine à machine, la compréhension des types d’octroi OAuth 2.0 peut vous aider à mettre en œuvre un mécanisme d’authentification et d’autorisation robuste et sécurisé.

Dans cet article de blog, nous vous présentons vous montrer les différents octrois OAuth 2.0 et comment les implémenter dans Amazon Cognito. Nous examinons l’objectif de chaque subvention, sa pertinence dans le développement d’applications modernes et la subvention la mieux adaptée aux différentes exigences de l’application.

OAuth 2.0 est un cadre d’autorisation qui permet un accès sécurisé et transparent aux ressources pour le compte des utilisateurs sans avoir à partager d’informations d’identification sensibles. L’objectif principal d’OAuth 2.0 est d’établir un mécanisme d’accès sécurisé, délégué et limité qui permet aux applications tierces d’interagir avec les données des utilisateurs tout en maintenant des mesures de confidentialité et de sécurité robustes.

OpenID Connect, souvent appelé OIDC, est un protocole basé sur OAuth 2.0. Il étend OAuth 2.0 pour fournir l’authentification de l’utilisateur, la vérification de l’identité et la récupération des informations de l’utilisateur. OIDC est un composant crucial pour créer des expériences d’authentification sécurisées et conviviales dans les applications. Amazon Cognito prend en charge OIDC, c’est-à-dire qu’il prend en charge l’authentification des utilisateurs et la vérification de l’identité selon les normes OIDC.

Amazon Cognito est un environnement d’identité pour les applications Web et mobiles. Ses deux composants principaux sont les pools d’utilisateurs et les pools d’identités. Un groupe d’utilisateurs Cognito est un annuaire d’utilisateurs, un serveur d’authentification et un service d’autorisation pour les jetons OAuth 2.0. Grâce à lui, vous pouvez authentifier et autoriser des utilisateurs en mode natif ou à partir d’une identité fédérée telle que votre annuaire d’entreprise, ou de fournisseurs d’identité grand public tels que Google ou Facebook. Cognito Identity Pool peut échanger des jetons OAuth 2.0 (entre autres options) contre des informations d’identification AWS.

Mise en œuvre d’octrois OAuth 2.0 à l’aide d’Amazon Cognito

La norme OAuth 2.0 définit quatre rôles principaux, qu’il est important de connaître lorsque nous abordons les octrois :

• Un propriétaire de ressource est propriétaire des données de la ressource serveur et peut accorder l’accès à la ressource (par exemple, un administrateur de base de données).
• Un serveur de ressources héberge les ressources protégées auxquelles l’application souhaite accéder (par exemple, un serveur SQL).
• Un client est une application qui demande les ressources protégées pour le compte du propriétaire de la ressource et avec son autorisation (par exemple, une application d’analyse).
• Un serveur d’autorisation est un serveur qui émet des jetons délimités une fois que l’utilisateur s’est authentifié et a consenti à l’émission du jeton dans le cadre de l’étendue souhaitée (par exemple, Amazon Cognito).

Quelques autres concepts utiles avant de nous plonger dans les subventions OAuth 2.0 :

• Les jetons d’accès sont au cœur du fonctionnement d’OAuth 2.0. Ces jetons sont des informations d’identification de courte durée que l’application cliente utilise pour prouver son statut autorisé lorsqu’elle demande des ressources à le serveur de ressources. En outre, OAuth 2.0 peut impliquer l’utilisation de jetons d’actualisation, qui fournissent un mécanisme permettant aux clients d’obtenir de nouveaux jetons d’accès sans nécessiter l’intervention du propriétaire de la ressource.
• Un jeton d’ID est un jeton Web JSON (JWT) introduit par OpenID Connect qui contient des informations sur l’événement d’authentification de l’utilisateur. Ils permettent aux applications de vérifier l’identité de l’utilisateur, de prendre des décisions éclairées sur l’état d’authentification de l’utilisateur et de personnaliser l’expérience de l’utilisateur.
• Une étendue est un niveau d’accès qu’une application peut demander à une ressource. Les étendues définissent les autorisations spécifiques qu’une application cliente peut demander lors de l’obtention d’un jeton d’accès. Vous pouvez utiliser des étendues pour affiner le niveau d’accès accordé au client. Par exemple, une demande OAuth 2.0 peut inclure l’étendue read :profile, indiquant que l’application cliente demande un accès en lecture seule à l’application les informations de profil de l’utilisateur. Une autre demande peut inclure la portée write :photos, indiquant que le client a besoin d’écrire dans la collection de photos de l’utilisateur. Dans Amazon Cognito, vous pouvez définir des étendues personnalisées ainsi que des étendues OAuth 2.0 standard telles que openid, profile, email ou phone pour vous aligner sur les exigences de votre application. Vous pouvez utiliser cette flexibilité pour gérer les autorisations d’accès de manière efficace et sécurisée.

Un flux OAuth 2.0 de haut niveau typique ressemble à la Figure 1 :

Vous trouverez ci-dessous les étapes impliquées dans le flux OAuth 2.0

1. Le client demande l’autorisation du propriétaire de la ressource. Cela se fait par le biais du serveur d’autorisation (Amazon Cognito) en tant qu’intermédiaire.
2. Le propriétaire de la ressource fournit l’octroi de l’autorisation au client. Il peut s’agir de l’un des nombreux types de subventions, qui sont abordés en détail dans la paragraphe suivant. Le type d’octroi utilisé dépend de la méthode utilisée par le client pour demander l’autorisation au propriétaire de la ressource.
3. Le client demande un jeton d’accès en s’authentifiant auprès de Cognito.
4. Cognito authentifie le client (méthode d’authentification basée sur le type d’autorisation) et émet un jeton d’accès si l’autorisation est valide.
5. Le jeton d’accès est présenté au serveur de ressources lorsque le client demande la ressource protégée.
6. Le serveur de ressources vérifie la signature et les attributs du jeton d’accès et traite la demande si elle est valide.

Il existe plusieurs types de subventions, dont quatre sont décrits dans les sections suivantes.

Le

type d’octroi de code d’autorisation est utilisé par les clients pour échanger en toute sécurité un code d’autorisation contre un jeton d’accès. Il est utilisé par les deux applications Web et les applications natives pour obtenir un jeton d’accès une fois qu’un utilisateur s’est authentifié auprès d’une application. Une fois que l’utilisateur revient au client via l’URI de redirection (l’URL où le serveur d’authentification redirige le navigateur après avoir autorisé l’utilisateur), l’application obtient le code d’autorisation de l’URL et l’utilise pour demander un jeton d’accès.

Ce type d’octroi convient aux cas généraux car un seul flux d’authentification est utilisé, quelle que soit l’opération effectuée ou la personne qui l’effectue. Cette autorisation est considérée comme sécurisée car elle demande un jeton d’accès avec un code à usage unique au lieu d’exposer les jetons d’accès réels. Cela permet d’empêcher l’application d’accéder potentiellement aux informations d’identification de l’utilisateur.

Vous trouverez ci-dessous les étapes impliquées dans le flux d’octroi du code d’autorisation

1. Le processus commence par l’initiation du client La séquence, dirigeant l’agent utilisateur (c’est-à-dire le navigateur) du propriétaire de la ressource vers le point de terminaison d’autorisation. Dans cette action, le client fournit son identificateur client, l’étendue qu’il demande, un état local et une URI de redirection à laquelle le serveur d’autorisation (Amazon Cognito) renverra l’agent utilisateur après avoir accordé ou refusé l’accès.
2. Cognito authentifie le propriétaire de la ressource (par l’intermédiaire de l’agent utilisateur) et détermine si le propriétaire de la ressource accorde ou refuse la demande d’accès du client à l’aide de l’authentification par pool d’utilisateurs.
3. Cognito redirige l’agent utilisateur vers le client à l’aide de l’URI de redirection fourni à l’étape (1) avec un code d’autorisation dans la chaîne de requête (par exemple, http://www.example.com/webpage?code=<authcode>).
4. Le client demande un jeton d’accès à partir du point de terminaison de jeton de Cognito en incluant le code d’autorisation reçu à l’étape (3). Quand à l’origine de la demande, le client s’authentifie auprès de Cognito, généralement à l’aide d’un ID client et d’un code secret. Le client inclut l’URI de redirection utilisé pour obtenir le code d’autorisation à des fins de vérification.
5. Cognito authentifie le client, valide le code d’autorisation et s’assure que l’URI de redirection reçu correspond à l’URI utilisé pour rediriger le client à l’étape (3). S’il est valide, Cognito répond avec un jeton d’accès.

Une implémentation de l’octroi du code d’autorisation à l’aide d’Amazon Cognito se présente comme suit :

1. Une application effectue une requête HTTP à , où représente le domaine configuré du groupe d’utilisateurs. Cette demande inclut les paramètres de requête suivants :
   • – Définissez la valeur sur pour ce type d’autorisation.
   • – L’ID du client d’application de pool d’utilisateurs souhaité.
   • – L’URL vers laquelle un utilisateur est dirigé après une authentification réussie.
   • (facultatif mais recommandé) : valeur aléatoire utilisée pour empêcher les attaques CSRF (Cross-Site Request Forgery).
   • (facultatif) – Une liste d’étendues séparées par des espaces à demander pour les jetons générés. Notez que :
     • Un jeton d’ID n’est généré que si l’étendue est demandée.
     • Les portées , , et ne peuvent être demandées que si elles sont également demandées.
     • Un jeton d’accès vendu ne peut être utilisé pour effectuer des appels d’API de pool d’utilisateurs que si (étendue d’API réservée du groupe d’utilisateurs) est demandée.
   • (facultatif) – Indique le fournisseur avec lequel l’utilisateur final doit s’authentifier.
   • (facultatif) – Identique au vrai nom du fournisseur, mais ne l’expose pas.
   • (facultatif) – Une valeur aléatoire que vous pouvez ajouter à la demande. La valeur que vous fournissez est incluse dans le jeton d’ID émis par Amazon Cognito. Pour se prémunir contre les attaques par rejeu, votre application peut inspecter la revendication nonce dans l’ID token et comparez-le à celui que vous avez généré. Pour plus d’informations sur la revendication nonce, consultez Validation du jeton d’ID dans la norme OpenID Connect.
2. Si un fournisseur d’identité a été spécifié dans la demande à partir de l’étape 1, le reste de cette étape est ignoré. L’utilisateur est automatiquement redirigé vers la page d’authentification du fournisseur d’identité approprié. Sinon, l’utilisateur est redirigé vers https ://AUTH_DOMAIN/login (qui héberge l’interface utilisateur générée automatiquement) avec les mêmes paramètres de requête définis à l’étape 1. Ils peuvent ensuite s’authentifier auprès du groupe d’utilisateurs ou sélectionner l’un des fournisseurs tiers configurés pour le client d’application désigné.
3. L’utilisateur s’authentifie auprès de son fournisseur d’identité par l’un des moyens suivants :
   1. Si l’utilisateur utilise le groupe d’utilisateurs natif pour s’authentifier, l’interface utilisateur hébergée soumet les informations d’identification de l’utilisateur par le biais d’une demande à https ://AUTH_DOMAIN/login (y compris les paramètres de requête d’origine) ainsi que quelques métadonnées supplémentaires.
   2. Si l’utilisateur sélectionne un autre fournisseur d’identité avec lequel s’authentifier, il est redirigé vers la page d’authentification de ce fournisseur d’identité. Une fois l’authentification réussie, le fournisseur redirige l’utilisateur vers https ://AUTH_DOMAIN/saml2/idpresponse avec un jeton d’autorisation dans le paramètre de requête ou une assertion SAML dans une demande.
4. Une fois qu’Amazon Cognito a vérifié les informations d’identification du groupe d’utilisateurs ou les jetons de fournisseur qu’il reçoit, l’utilisateur est redirigé vers l’URL spécifiée dans le paramètre de requête d’origine. La redirection définit également un paramètre de requête qui spécifie le code d’autorisation qui a été vendu à l’utilisateur par Cognito.
5. L’application personnalisée hébergée à l’URL de redirection peut ensuite extraire le code d’autorisation des paramètres de requête et l’échanger contre des jetons de pool d’utilisateurs. L’échange se produit en soumettant une demande à https ://AUTH_DOMAIN/OAuth2/token avec les paramètres suivants :
   • – Définir sur pour cette autorisation.
   • – Le code d’autorisation qui est vendu à l’utilisateur.
   • – Identique à la demande à l’étape 1.
   • – Identique à la demande à l’étape 1.

Si l’application cliente a été configurée avec un code secret, l’en-tête de cette demande est défini comme suit : , où est la représentation en base64 de l’ID du client de l’application et du secret du client de l’application, concaténée par deux points.

Le JSON renvoyé dans la réponse résultante comporte les clés suivantes :

• – Un jeton d’accès au pool d’utilisateurs valide.
• – Un jeton d’actualisation du pool d’utilisateurs valide. Cela peut être utilisé pour récupérer de nouveaux jetons en les envoyant via une requête à , en spécifiant les paramètres et et en définissant le paramètre sur .
• – Un ID de groupe d’utilisateurs valide jeton. Notez qu’un jeton d’ID n’est fourni que si l’étendue a été demandée.
• – La durée (en secondes) de validité de l’ID ou des jetons d’accès fournis.
• –se mettre à.

Voici quelques-unes des bonnes pratiques à suivre lors de l’utilisation de l’octroi de code d’autorisation :

• Utilisez l’extension PKCE (Proof Key for Code Exchange) avec l’octroi de code d’autorisation, en particulier pour les clients publics tels qu’une application web à page unique. Ceci est abordé plus en détail dans la section suivante.
• Faites régulièrement pivoter les clés secrètes et les informations d’identification des clients afin de minimiser le risque d’accès non autorisé.
• Mettez en œuvre la gestion des sessions pour gérer les sessions utilisateur en toute sécurité. Cela implique de gérer la durée de vie des jetons d’accès, de stocker des jetons, de faire tourner les jetons d’actualisation, de mettre en œuvre des révocations de jetons et de fournir des mécanismes de déconnexion simples qui invalident l’accès et actualisent les jetons sur appareils de l’utilisateur.

Pour

renforcer la sécurité lors de l’utilisation de l’octroi de code d’autorisation, en particulier dans les clients publics tels que les applications natives, l’extension PKCE a été introduite. PKCE ajoute une couche de protection supplémentaire en s’assurant que seul le client qui a initié le processus d’autorisation peut échanger le code d’autorisation reçu contre un jeton d’accès. Cette combinaison est parfois appelée subvention PKCE.

Il introduit un secret appelé vérificateur de code , qui est une valeur aléatoire créée par le client pour chaque demande d’autorisation. Cette valeur est ensuite hachée à l’aide d’une méthode de transformation telle que SHA256, ce qu’on appelle désormais le défi de code. Les mêmes étapes sont suivies que le flux de la figure 2, mais la demande de code est désormais ajoutée à la chaîne de requête pour la demande au serveur d’autorisation (Amazon Cognito). Le Le serveur d’autorisation stocke ce test de code pour vérification après le processus d’authentification et le redirige avec un code d’autorisation. Ce code d’autorisation, ainsi que le vérificateur de code, sont envoyés au serveur d’autorisation, qui compare ensuite la demande de code précédemment stockée avec le vérificateur de code. Les jetons d’accès sont émis une fois la vérification terminée avec succès. La figure 3 décrit ce processus.

L’octroi du code d’autorisation avec l’implémentation PKCE est identique à l’octroi du code d’autorisation, sauf que l’étape 1 nécessite deux paramètres de requête supplémentaires :

• – La représentation hachée et encodée en URL base64 d’un code aléatoire généré côté client (vérificateur de code). Il sert de PKCE, qui empêche les acteurs malveillants d’utiliser des codes d’autorisation interceptés.
• – L’algorithme de hachage qui est utilisé pour générer le fichier . À l’heure actuelle, Amazon Cognito ne prend en charge que la définition de ce paramètre sur S256. Cela indique que le paramètre a été généré à l’aide de SHA-256.

À l’étape 5, lors de l’échange du code d’autorisation avec le jeton du pool d’utilisateurs, incluez un paramètre supplémentaire :

• – La représentation encodée en URL base64 de la chaîne aléatoire non hachée qui a été utilisée pour générer le PKCE dans la demande d’origine.

Octroi implicite (non recommandé)

L’octroi implicite était un type d’octroi d’authentification OAuth 2.0 qui permettait aux clients, tels que les applications monopages et les applications mobiles, d’obtenir des jetons d’accès utilisateur directement à partir du point de terminaison d’autorisation. Le type d’octroi était implicite, car aucune information d’identification intermédiaire (telle qu’un code d’autorisation) n’a été émise et utilisée ultérieurement pour obtenir un jeton d’accès. L’octroi implicite a été déprécié et il est recommandé d’utiliser octroi de code d’autorisation avec PKCE à la place. L’utilisation de l’octroi implicite avait pour effet d’exposer les jetons d’accès directement dans le fragment d’URL, qui pouvaient potentiellement être enregistrés dans l’historique du navigateur, interceptés ou exposés à d’autres applications résidant sur le même appareil.

Le flux d’octroi implicite a été conçu pour permettre aux applications publiques côté client, telles que les applications à page unique ou les applications mobiles sans composant de serveur principal, d’échanger des codes d’autorisation contre des jetons.

Les étapes 1, 2 et 3 de l’octroi implicite sont identiques aux étapes d’octroi du code d’autorisation, sauf que le paramètre de requête est défini sur . De plus, bien qu’un défi PKCE puisse techniquement être réussi, il n’est pas utilisé car le point de terminaison n’est jamais accessible. Les étapes suivantes, en commençant par l’étape 4, sont les suivantes :

1. Une fois qu’Amazon Cognito a vérifié le les informations d’identification du pool d’utilisateurs ou les jetons de fournisseur qu’il reçoit, l’utilisateur est redirigé vers l’URL spécifiée dans le paramètre de requête d’origine. La redirection définit également les paramètres de requête suivants :
   • – Un jeton d’accès au pool d’utilisateurs valide.
   • – La durée (en secondes) de validité de l’ID ou des jetons d’accès fournis.
   • –se mettre à.
   • – Un jeton d’ID de groupe d’utilisateurs valide. Notez qu’un jeton d’ID n’est fourni que si l’étendue a été demandée.

   Notez qu’aucun jeton d’actualisation n’est renvoyé lors d’une attribution implicite, comme spécifié dans la norme RFC.

2. L’application personnalisée hébergée à l’URL de redirection peut ensuite extraire le jeton d’accès et le jeton d’ID (s’ils sont présents) à partir des paramètres de requête.

Voici quelques bonnes pratiques pour l’octroi implicite :

• Réduisez la durée de vie des jetons d’accès. Jetons d’octroi implicites ne peuvent pas être révoqués, donc l’expiration est le seul moyen de mettre fin à leur validité.
• Le type d’octroi implicite est obsolète et ne doit être utilisé que pour les scénarios où un composant de serveur principal ne peut pas être implémenté, tels que les applications basées sur un navigateur.

Octroi des informations d’identification du client L’octroi

des

informations d’identification du client est destiné à l’authentification de machine à machine. Par exemple, une application tierce doit vérifier son identité avant de pouvoir accéder à votre système. Le client peut demander un jeton d’accès en utilisant uniquement ses informations d’identification client (ou d’autres moyens d’authentification pris en charge) lorsqu’il demande l’accès aux ressources protégées sous son contrôle ou à celles d’un autre propriétaire de ressources qui ont été précédemment organisées avec le serveur d’autorisation.

Le type d’octroi d’informations d’identification du client ne doit être utilisé que par les clients confidentiels. Cela signifie que le client doit avoir la possibilité de protéger une chaîne secrète des utilisateurs. Notez que pour utiliser l’octroi des informations d’identification du client, le client d’application du groupe d’utilisateurs correspondant doit disposer d’une clé secrète client d’application associée.

Le flux illustré à la figure 5 comprend les étapes suivantes :

1. Le client s’authentifie auprès du serveur d’autorisation à l’aide d’un ID client et d’un secret et demande un jeton d’accès à partir du point de terminaison du jeton.
2. Le serveur d’autorisation authentifie le client et, s’il est valide, émet un jeton d’accès.

Les étapes détaillées du processus sont les suivantes :

1. L’application effectue une requête à , et spécifie les paramètres suivants :
   • – Défini sur pour ce type d’octroi.
   • – L’ID du client d’application de pool d’utilisateurs souhaité.
   • – Une liste d’étendues séparées par des espaces à demander pour le jeton d’accès généré. Notez que vous Ne peut utiliser une étendue personnalisée qu’avec l’octroi des informations d’identification du client.

Afin d’indiquer que l’application est autorisée à effectuer la demande, l’en-tête de cette demande est défini comme suit : , où est la représentation en base64 de l’ID client et de la clé secrète client, concaténée par deux points.

Le serveur d’autorisation Amazon Cognito renvoie un objet JSON avec les clés suivantes :

• – Un jeton d’accès au pool d’utilisateurs valide.
• – La durée (en secondes) de validité du jeton d’accès fourni.
• –se mettre à.

Notez que, pour ce type d’octroi, un jeton d’ID et un jeton d’actualisation ne sont pas renvoyés.

1. L’application utilise le jeton d’accès pour envoyer des requêtes à un serveur de ressources associé.
2. Le serveur de ressources valide le jeton reçu et, si tout se passe bien, traite la demande à partir de la appli.

Voici quelques pratiques recommandées lors de l’utilisation de l’octroi d’informations d’identification client :

• Stockez les informations d’identification du client en toute sécurité et évitez de les coder en dur dans votre application. Utilisez des pratiques de gestion des informations d’identification appropriées, telles que des variables d’environnement ou des services de gestion des secrets.
• Limitez les cas d’utilisation. L’octroi des informations d’identification du client convient à l’authentification de machine à machine dans des scénarios hautement fiables. Limiter son utilisation aux cas où les autres types de subventions ne s’appliquent pas.

Les

octrois d’extension permettent d’ajouter la prise en charge de scénarios d’émission de jetons non standard, tels que la traduction de jetons, la délégation ou les informations d’identification personnalisées. Il vous permet d’échanger des jetons d’accès d’un service d’autorisation OAuth 2.0 tiers avec des jetons d’accès d’Amazon Cognito. En définissant le type d’octroi à l’aide d’un URI absolu (déterminé par l’autorisation server) comme valeur de l’argument grant_type du point de terminaison de jeton et, en ajoutant d’autres paramètres requis, le client peut utiliser un type d’octroi d’extension.

Un exemple d’octroi d’extension est l’octroi d’autorisation de périphérique OAuth 2.0 (RFC 8628). Cette autorisation permet aux appareils connectés à Internet dont les capacités de saisie sont limitées ou qui ne disposent pas d’un navigateur convivial (tels que les appareils portables, les assistants intelligents, les appareils de diffusion vidéo en continu, la domotique et les appareils médicaux ou de santé) d’examiner la demande d’autorisation sur un appareil secondaire, tel qu’un smartphone, qui dispose de capacités de saisie et de navigateur plus avancées.

Voici quelques-unes des bonnes pratiques à suivre lorsque vous décidez d’utiliser des autorisations d’extension :

• Les autorisations d’extension concernent des scénarios d’émission de jetons non standard. Ne les utilisez qu’en cas de nécessité et documentez minutieusement leur utilisation et leur objectif.
• Assurer la sécurité audits et revues de code lors de la mise en œuvre d’Extension grants afin d’identifier les vulnérabilités potentielles et d’atténuer les risques.

Bien qu’Amazon Cognito ne prenne actuellement pas en charge nativement les octrois d’extension, voici un exemple d’implémentation du flux d’octroi d’appareils OAuth 2.0 à l’aide d’AWS Lambda et d’Amazon DynamoDB.

Conclusion

Dans cet article de blog, nous avons passé en revue diverses subventions OAuth 2.0, chacune répondant à des besoins spécifiques des applications, L’octroi de code d’autorisation garantit un accès sécurisé pour les applications Web (et offre une sécurité supplémentaire avec l’extension PKCE), et l’octroi d’informations d’identification client est idéal pour l’authentification de machine à machine. Amazon Cognito agit comme une plate-forme d’identité globale, rationalisant l’authentification, l’autorisation et l’intégration des utilisateurs. En utilisant ces subventions et les fonctionnalités fournies par Cognito, les développeurs peuvent améliorer la sécurité et l’expérience utilisateur dans leurs applications. Pour en savoir plus pour plus d’informations et d’exemples, consultez la section Octrois OAuth 2.0 dans le Guide du développeur Cognito.

Maintenant que vous comprenez l’implémentation des octrois OAuth 2.0 dans Amazon Cognito, consultez Comment personnaliser les jetons d’accès dans les groupes d’utilisateurs Amazon Cognito pour en savoir plus sur la personnalisation des jetons d’accès afin de prendre des décisions d’autorisation précises et d’offrir une expérience différenciée à l’utilisateur final.

Si vous avez des commentaires sur cet article, soumettez-les dans la section Commentaires ci-dessous. Si vous avez des questions sur cet article, contactez AWS Support.

MOTS CLÉS : Amazon Cognito, Blog sur la sécurité