Les utilisateurs s'authentifient auprès d'une API via un IdP tiers via Amazon Cognito. Le développeur a mappé l'attribut IdP Department à un autorisateur Lambda personnalisé, dans l'intention de n'autoriser que les utilisateurs du service commercial (Sales). Le développeur modifie son service en Sales dans l'IdP, mais l'accès lui est toujours refusé ; les journaux montrent que le jeton d'accès a toujours Department=Engineering. Qu'est-ce qui pourrait expliquer pourquoi le jeton indique toujours Engineering au lieu de Sales ?

L'explication la plus probable est que la mise en cache de l'autorisation est activée sur l'autorisateur Lambda personnalisé. Lorsque la mise en cache est activée, l'autorisateur réutilise les décisions d'autorisation précédentes pour une période donnée, même si les attributs sous-jacents de l'utilisateur ont changé dans l'IdP. Le développeur a modifié le département dans l'IdP, mais l'autorisateur Lambda utilise toujours une décision mise en cache basée sur l'ancien attribut "Engineering". Les autres options sont incorrectes : La mise en cache sur le pool d'utilisateurs Amazon Cognito n'affecterait pas la valeur de l'attribut transmise à l'autorisateur Lambda. Les rôles IAM n'utilisent pas de balises pour les attributs d'utilisateur de cette manière ; les attributs sont gérés par le mappage d'attributs de Cognito et l'IdP.