Jetons de mise en cache

Votre application doit exécuter avec succès l'une des demandes suivantes chaque fois que vous souhaitez obtenir un nouveau jeton Web JSON (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 le cadre d'une demande d'API Amazon 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-machine activité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 OAuth 2.0 Amazon Cognito comprennent le point de terminaison du jeton, qui gère les informations d'identification du client et les demandes de code d'autorisation de l’interface utilisateur hébergée. Les points de terminaison de service répondent à des demandes d'API de groupes d'utilisateurse comme InitiateAuth et RespondToAuthChallenge. 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 API Gateway

Grâce à la mise en cache des jetons API Gateway, votre application peut faire l’objet d’une mise à l’échelle en réponse à des événements plus importants que le quota de taux de demandes par défaut des points de terminaison OAuth d’Amazon Cognito.

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 d'API Amazon Cognito. Lorsque vous utilisez Amazon API Gateway en tant que proxy pour le Point de terminaison de jeton, votre API répond à la majorité des demandes qui, dans le cas contraire, contribueraient à votre quota de demandes. Cela permet d’éviter les demandes infructueuses liées à la limitation du taux.

La solution suivante, basée sur l’API Gateway, propose une mise en œuvre de la mise en cache des jetons à faible latence, à codage faible ou sans codage. Les API API Gateway sont chiffrées en transit et, éventuellement, au repos. Un cache API Gateway est idéal pour l'octroi d'informations d'identification au client OAuth 2.0, un type de subvention souvent important qui produit des jetons d'accès pour autoriser des sessions de microservice machine-to-machine et d'autorisation. 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 dans votre API afin de stocker un jeton d'accès distinct pour chaque combinaison de portées OAuth et de client d'application que vous souhaitez demander dans votre application. Lorsque votre application fait une demande qui correspond à la clé de cache, votre API répond avec un jeton d'accès qu'Amazon Cognito a émis à la première demande correspondant à la clé de cache. Lorsque la durée de votre clé de cache expire, votre API transmet la demande au point de terminaison de votre jeton et met 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 portées OAuth que vous demandez dans le paramètre d'URL scope et l’en-tête Authorization 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 for Redis. Pour un contrôle précis avec les politiques AWS Identity and Access Management (IAM), envisagez 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 API Gateway

1. Ouvrez la console API Gateway et créez une API REST.

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

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

   2. Sélectionnez Use HTTP proxy integration (Utiliser une intégration proxy HTTP).

   3. Saisissez une URL de point de terminaison de https://<your user pool domain>/oauth2/token.

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

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

   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 requête dans URL query string parameters (Paramètres de chaîne de requête d'URL) et choisissez Caching (Mise en cache) pour la chaîne scope.

      2. Ajoutez un en-tête à HTTP request headers (En-têtes de demande HTTP) et choisissez Caching (Mise en cache) pour l’en-tête Authorization.

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

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

   2. Sous Settings (Paramètres), sélectionnez Enable API cache (Activer le cache d'API).

   3. Choisissez une capacité de cache.

   4. Choisissez un cache time-to-live (TTL) d'au moins 3 600 secondes.

   5. Décochez la case Exiger une autorisation.

5. Dans Stages (Étapes), notez l’URL d’appel.

6. Mettez à jour votre application pour envoyer des demandes de jetons POST à l’URL d’appel de votre API plutôt qu’au point de terminaison /oauth2/token de votre groupe d'utilisateurs.