Użytkownicy uwierzytelniają się w API za pośrednictwem zewnętrznego IdP poprzez Amazon Cognito. Deweloper zmapował atrybut IdP Department do niestandardowego autoryzatora Lambda, zamierzając zezwolić tylko użytkownikom z działu Sales. Deweloper zmienia swój dział na Sales w IdP, ale nadal odmawia mu się dostępu; logi pokazują, że token dostępu nadal ma Department=Engineering. Co może wyjaśniać, dlaczego token nadal zgłasza Engineering zamiast Sales?

Poprawna odpowiedź to: Buforowanie autoryzacji jest włączone w niestandardowym autoryzatorze Lambda. Gdy buforowanie autoryzacji jest włączone dla niestandardowego autoryzatora Lambda, autoryzator przechowuje w pamięci podręcznej odpowiedzi autoryzacyjne dla określonego tokenu przez konfigurowalny czas (TTL). Jeśli deweloper zmieni swój atrybut Department w IdP, ale token dostępu, którego używa, został już uwierzytelniony i jego odpowiedź jest buforowana, autoryzator będzie nadal używał buforowanej odpowiedzi, która zawiera stary atrybut (Engineering), dopóki bufor nie wygaśnie lub token nie zostanie odświeżony. Niepoprawne opcje: Buforowanie autoryzacji jest włączone w puli użytkowników Amazon Cognito: Pule użytkowników Cognito nie mają wbudowanej funkcji buforowania autoryzacji w taki sposób, który wpływałby na atrybuty w tokenie dostępu po jego wygenerowaniu. Rola IAM dla niestandardowego autoryzatora Lambda nie posiada tagu Department: Rola IAM autoryzatora Lambda dotyczy uprawnień, jakie autoryzator ma do wykonywania swoich funkcji, a nie atrybutów użytkownika przekazywanych w tokenie. Rola IAM dla puli użytkowników Amazon Cognito nie posiada tagu Department: Podobnie jak wyżej, rola IAM puli użytkowników Cognito dotyczy uprawnień puli, a nie danych użytkownika w tokenie.