Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Analizza i token del pool di utenti in modo sicuro
Il set di claim di un token Amazon Cognito non è fisso. Le affermazioni supportate dal token variano a seconda del flusso di autenticazione, dell'appartenenza al gruppo dell'utente, del provider di identità e delle funzionalità abilitate nel pool di utenti. Amazon Cognito aggiunge nuove attestazioni in modo progressivo nel tempo: introduce nuove chiavi, ma non rinomina, modifica il tipo o rimuove le attestazioni esistenti documentate in questa guida. Queste regole si applicano sia ai token ID che ai token di accesso.
Non scrivere il tuo parser di token. Usa una libreria di token web JSON (JWT) e un parser JSON che continuano a funzionare man mano che il token cresce. Le due regole che impediscono quasi tutte le violazioni nel mondo reale sono le prime due seguenti: tollera le affermazioni che non riconosci e fai le giuste ipotesi sul tipo e sulla cardinalità di ogni affermazione che leggi.
- Ignora le affermazioni che non riconosci
-
Leggi le affermazioni di cui ha bisogno la tua candidatura e lascia perdere il resto. Non rifiutare, fallire o generare un errore quando un token riporta un'affermazione che non è elencata in questa guida. Le nuove attestazioni vengono aggiunte in modo aggiuntivo e un token che contiene un'attestazione non elencata è ancora valido.
- Leggi ogni reclamo nel suo tipo documentato
-
Un parser JSON identifica il tipo primitivo di ogni valore dal JSON stesso, quindi il rischio sta nelle ipotesi che il codice fa su quel valore. Considera ogni affermazione come il tipo e la cardinalità che questa guida documenta. Un'affermazione documentata come matrice è sempre una matrice, anche quando attualmente contiene un singolo valore. Non comprimerlo in una stringa. Ad esempio,
cognito:groupscognito:roles, eidentitiessono sempre matrici. Lo stesso principio si applica alle rivendicazioni definite da altre specifiche. Ad esempioamr, quando è presente, è presente un array di stringhe come definito nella RFC 8176sul sito Web IETF, quindi leggilo in quel tipo. - Non convalidate eccessivamente i formati di attestazione
-
Convalida ciò che richiede la specifica di un reclamo e non di più. Ad esempio,
subè una stringa unica ma non è garantito che sia in un particolare formato UUID. Alcuni valori all'interno di dichiarazioni personalizzate, ad esempioidentitiesquelli serializzati come stringhe anziché come valori booleani o numeri JSON, e non è garantito che i valori opachi abbiano una lunghezza particolare. L'imposizione di un formato più rigoroso rispetto agli stati della documentazione causa il fallimento dei token validi. - Non date per scontato il numero di reclami o il loro ordine
-
Le rivendicazioni in un token possono apparire in qualsiasi ordine e il conteggio può variare da un token all'altro e nel tempo. Indirizza ogni affermazione per nome anziché per posizione e analizza il token come un oggetto JSON generale anziché come una struttura fissa.
- Budget per la crescita delle dimensioni dei token
-
Poiché il set di claim cresce, cresce anche la dimensione complessiva del token. Non presupponete una dimensione fissa o massima del token nei buffer, nella larghezza delle colonne, nelle intestazioni o nei cookie.
Il documento di openid-configuration scoperta segue lo stesso approccio additivo e compatibile con le versioni precedenti. Per ulteriori informazioni sull'analisi sicura del documento, consulta. Preparati per le modifiche al documento di scoperta
