Los usuarios se autentican en una API a través de un IdP de terceros mediante Amazon Cognito. El desarrollador mapeó el atributo Department del IdP a un autorizador de Lambda personalizado, con la intención de permitir solo a los usuarios del departamento de Ventas. El desarrollador cambia su departamento a Ventas en el IdP, pero se le sigue denegando el acceso; los registros muestran que el token de acceso todavía tiene Department=Engineering. ¿Qué podría explicar por qué el token sigue reportando Engineering en lugar de Sales?

La respuesta correcta es que el almacenamiento en caché de autorización está habilitado en el autorizador de Lambda personalizado. Cuando el almacenamiento en caché está habilitado, el autorizador de Lambda almacena en caché las decisiones de autorización durante un período predefinido. Si el usuario ya había intentado acceder a la API con el atributo Department=Engineering, esa decisión se almacenó en caché. Aunque el atributo se actualizó en el IdP, el autorizador sigue utilizando la decisión en caché hasta que expire o se invalide. Las otras opciones son incorrectas: Amazon Cognito no tiene una función de "almacenamiento en caché de autorización en el grupo de usuarios" que afecte directamente a los tokens de acceso de esta manera. Cognito actualiza los atributos del usuario cuando se sincronizan con el IdP. Los roles de IAM no utilizan "etiquetas Department" para la autorización de Lambda o Cognito en este contexto. La autorización se basa en políticas de IAM y los atributos del token de Cognito.