Gli utenti si autenticano a un'API tramite un IdP di terze parti attraverso Amazon Cognito. Lo sviluppatore ha mappato l'attributo IdP Department a un authorizer Lambda personalizzato, con l'intenzione di consentire l'accesso solo agli utenti del reparto Vendite. Lo sviluppatore cambia il proprio reparto in Vendite nell'IdP ma gli viene comunque negato l'accesso; i log mostrano che il token di accesso ha ancora Department=Engineering. Cosa potrebbe spiegare perché il token riporta ancora Engineering invece di Sales?

La memorizzazione nella cache dell'autorizzazione (authorization caching) è abilitata per impostazione predefinita sugli authorizer Lambda personalizzati di API Gateway. Questo significa che API Gateway memorizza nella cache la decisione di autorizzazione per un determinato token di accesso per un periodo di tempo (TTL). Se l'utente tenta di accedere all'API con lo stesso token di accesso prima che il TTL scada, API Gateway utilizzerà la decisione memorizzata nella cache, che in questo caso è basata sull'attributo Department=Engineering presente nel token al momento della prima richiesta autorizzata. Anche se l'attributo viene aggiornato nell'IdP, il token di accesso esistente non riflette immediatamente la modifica finché non scade o non viene rigenerato. Le altre opzioni sono errate: La memorizzazione nella cache sul pool di utenti di Amazon Cognito non influisce direttamente sul contenuto del token di accesso una volta emesso o sulla decisione di autorizzazione di API Gateway. I tag sui ruoli IAM non sono direttamente correlati agli attributi utente all'interno dei token di accesso o alla logica di un authorizer Lambda per l'autorizzazione basata su attributi utente.