Gestion de l'expiration et de la mise en cache des jetons du pool d'utilisateurs - Amazon Cognito

Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Gestion de l'expiration et de la mise en cache des jetons du pool d'utilisateurs

Votre application doit réussir l'une des demandes suivantes chaque fois que vous souhaitez obtenir un nouveau jeton JSON Web (JWT).

  • Demandez des informations d'identification client ou un octroi de code d'autorisation à partir du Point de terminaison de jeton.

  • Demandez un octroi implicite à partir de votre interface utilisateur hébergée.

  • Authentifiez un utilisateur local dans une demande Amazon API Cognito telle que. InitiateAuth

Vous pouvez configurer votre groupe d'utilisateurs de manière à ce que les jetons expirent en fonction d’une valeur exprimée en minutes, en heures ou en jours. Pour garantir les performances et la disponibilité de votre application, utilisez les jetons Amazon Cognito pendant environ 75 % de leur durée de vie, puis récupérez les nouveaux jetons. Une solution de cache que vous créez pour votre application permet de conserver les jetons disponibles et empêche le rejet des demandes par Amazon Cognito lorsque votre taux de demandes est trop élevé. Une application côté client doit stocker les jetons dans un cache mémoire. Une application côté serveur peut ajouter un mécanisme de cache chiffré pour stocker les jetons.

Lorsque votre groupe d'utilisateurs génère un volume élevé d'utilisateurs ou d' machine-to-machineactivités, vous pouvez rencontrer les limites fixées par Amazon Cognito quant au nombre de demandes de jetons que vous pouvez effectuer. Pour réduire le nombre de demandes que vous envoyez aux points de terminaison Amazon Cognito, vous pouvez stocker et réutiliser les données d'authentification de manière sécurisée ou mettre en œuvre un backoff exponentiel et des nouvelles tentatives.

Les données d'authentification proviennent de deux classes de point de terminaison. Les points de terminaison Amazon Cognito OAuth 2.0 incluent le point de terminaison jeton, qui gère les informations d'identification des clients et les demandes de code d'autorisation de l'interface utilisateur hébergée. Les points de terminaison de service répondent aux API demandes des groupes d'utilisateurs telles que InitiateAuth etRespondToAuthChallenge. Chaque type de demande possède sa propre limite. Pour en savoir plus sur les limites, consultez Quotas dans Amazon Cognito.

Mise en cache des jetons machine-to-machine d'accès avec Amazon Gateway API

Grâce à la mise en cache des jetons API Gateway, votre application peut évoluer en réponse à des événements supérieurs au quota de taux de demandes par défaut des points de terminaison Amazon OAuth Cognito.

Schéma d'une API passerelle gérant un cache de jetons d'accès pour le M2M. Le API proxy traite la demande de jeton et renvoie un jeton mis en cache s'il est déjà valide.

Vous pouvez mettre en cache les jetons d'accès afin que votre application demande un nouveau jeton d'accès uniquement si un jeton mis en cache a expiré. Sinon, votre point de terminaison de mise en cache renvoie un jeton depuis le cache. Cela empêche tout appel supplémentaire vers un point de terminaison Amazon CognitoAPI. Lorsque vous utilisez Amazon API Gateway comme proxy pour lePoint de terminaison de jeton, vous API répondez à la majorité des demandes qui contribueraient autrement à votre quota de demandes, évitant ainsi les demandes infructueuses en raison de la limitation du débit.

La solution API basée sur Gateway suivante propose une implémentation de la mise en cache de jetons à faible latence, à faible code ou sans code. APIAPIsLes passerelles sont chiffrées en transit, et éventuellement au repos. Un cache API Gateway est idéal pour l'octroi d'informations d'identification client OAuth 2.0, un type de subvention souvent important qui produit des jetons d'accès pour autoriser machine-to-machine et des sessions de microservice. Dans un cas tel qu'une augmentation du trafic entraînant une mise à l'échelle horizontale de vos microservices, vous pouvez vous retrouver avec de nombreux systèmes utilisant les mêmes informations d'identification client à un volume supérieur à la limite de AWS taux de demandes de votre groupe d'utilisateurs ou de votre client d'application. Pour préserver la disponibilité des applications et une faible latence, une solution de mise en cache est la bonne pratique à appliquer dans de tels scénarios.

Dans cette solution, vous définissez un cache API pour stocker un jeton d'accès distinct pour chaque combinaison de OAuth scopes et de client d'application que vous souhaitez demander dans votre application. Lorsque votre application fait une demande qui correspond à la clé de cache, vous API répondez avec un jeton d'accès émis par Amazon Cognito à la première demande correspondant à la clé de cache. Lorsque la durée de validité de votre clé de cache expire, API vous transférez la demande à votre point de terminaison de jeton et mettez en cache un nouveau jeton d'accès.

Note

La durée de votre clé de cache doit être inférieure à la durée du jeton d'accès de votre client d'application.

La clé de cache est une combinaison des OAuth étendues que vous demandez dans le scope URL paramètre et de l'Authorizationen-tête de la demande. L’en-tête Authorization contient l'identifiant et le secret de votre client d’application. Vous n'avez pas besoin de mettre en œuvre une logique supplémentaire dans votre application pour appliquer cette solution. Vous devez uniquement mettre à jour votre configuration pour modifier le chemin d'accès au point de terminaison du jeton de votre groupe d'utilisateurs.

Vous pouvez également implémenter la mise en cache des jetons avec ElastiCache (RedisOSS). Pour un contrôle précis avec des politiques AWS Identity and Access Management (IAM), pensez à un cache Amazon DynamoDB.

Note

La mise en cache dans API Gateway est soumise à des frais supplémentaires. Consultez la tarification pour plus d’informations.

Pour configurer un proxy de mise en cache avec Gateway API

  1. Ouvrez la console API Gateway et créez un RESTAPI.

  2. Dans Ressources, créez une POST méthode.

    1. Choisissez le type HTTP d'intégration.

    2. Sélectionnez Utiliser l'intégration du HTTP proxy.

    3. Entrez un point URL de terminaison dehttps://<your user pool domain>/oauth2/token.

  3. Dans Resources (Ressources), configurez la clé de cache.

    1. Modifiez la demande de méthode de votre POST méthode.

    2. Définissez votre paramètre scope et votre en-tête Authorization comme clé de mise en cache.

      1. Ajoutez une chaîne de URLrequête aux paramètres de la chaîne de requête et choisissez Caching pour la scope chaîne.

      2. Ajoutez un en-tête aux en-têtes de HTTP demande et choisissez Caching pour l'Authorizationen-tête.

  4. Dans Stages (Étapes), configurez la mise en cache.

    1. Choisissez l’étape que vous souhaitez modifier.

    2. Sous Paramètres, sélectionnez Activer API le cache.

    3. Choisissez une capacité de cache.

    4. Choisissez un cache time-to-live (TTL) de 3 600 secondes.

    5. Décochez la case Exiger une autorisation.

  5. Dans Stages, notez l'Invoke URL.

  6. Mettez à jour votre application en fonction des demandes de POST jetons envoyées à l'Invoke URL de votre groupe d'utilisateurs API plutôt qu'au /oauth2/token point de terminaison de votre groupe d'utilisateurs.