Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Analyser les jetons du pool d'utilisateurs en toute sécurité
L'ensemble de réclamations d'un jeton Amazon Cognito n'est pas fixe. Les revendications portées par votre jeton varient en fonction du flux d'authentification, de l'appartenance au groupe de l'utilisateur, du fournisseur d'identité, ainsi que des fonctionnalités que vous activez sur votre groupe d'utilisateurs. Amazon Cognito ajoute de nouvelles revendications de manière additive au fil du temps : il introduit de nouvelles clés, mais il ne renomme pas, ne modifie pas le type ou ne supprime pas les revendications existantes documentées dans ce guide. Ces règles s'appliquent à la fois aux jetons d'identification et aux jetons d'accès.
N'écrivez pas votre propre analyseur de jetons. Utilisez une bibliothèque de jetons Web JSON (JWT) et un analyseur JSON qui continuent de fonctionner au fur et à mesure que le jeton grandit. Les deux règles qui empêchent presque toutes les ruptures du monde réel sont les deux premières ci-dessous : tolérez les affirmations que vous ne reconnaissez pas et faites les bonnes suppositions quant au type et à la cardinalité de chaque affirmation que vous lisez.
- Ignorez les affirmations que vous ne reconnaissez pas
-
Lisez les demandes dont votre demande a besoin et laissez le reste tranquille. Ne rejetez pas, n'échouez pas ou ne lancez pas d'erreur lorsqu'un jeton contient une réclamation qui n'est pas répertoriée dans ce guide. Les nouvelles demandes sont ajoutées de manière additive, et un jeton contenant une réclamation non répertoriée est toujours valide.
- Lisez chaque réclamation dans son type documenté
-
Un analyseur JSON identifie le type primitif de chaque valeur à partir du JSON lui-même. Le risque réside donc dans les hypothèses que votre code fait ensuite à propos de cette valeur. Traitez chaque réclamation selon le type et la cardinalité décrits dans ce guide. Une réclamation documentée sous forme de tableau est toujours un tableau, même s'il contient actuellement une seule valeur. Ne le réduisez pas à une chaîne. Par exemple,
cognito:groupscognito:roles, etidentitiessont toujours des tableaux. Le même principe s'applique aux allégations définies par d'autres spécifications. Par exempleamr, s'il est présent, un tableau de chaînes tel que défini dans la RFC 8176sur le site Web de l'IETF, alors lisez-le dans ce type. - Ne survalidez pas les formats de réclamation
-
Validez ce que le cahier des charges d'une réclamation exige, et rien de plus. Par exemple,
subil s'agit d'une chaîne unique mais il n'est pas garanti qu'elle soit dans un format UUID particulier. Certaines valeurs contenues dans les revendications personnalisées, par exemple,identitiessont sérialisées sous forme de chaînes plutôt que sous forme de booléens ou de nombres JSON, et il n'est pas garanti que les valeurs opaques aient une longueur particulière. L'imposition d'un format plus strict que celui indiqué dans la documentation entraîne l'échec des jetons valides. - Ne présumez pas le nombre de réclamations ou leur commande
-
Les réclamations contenues dans un jeton peuvent apparaître dans n'importe quel ordre, et le nombre peut changer entre les jetons et au fil du temps. Adressez chaque réclamation par son nom plutôt que par sa position, et analysez le jeton comme un objet JSON général plutôt que comme une structure fixe.
- Budget pour augmenter la taille des jetons
-
À mesure que l'ensemble de réclamations augmente, la taille globale du jeton augmente également. Ne supposez pas une taille de jeton fixe ou maximale dans les tampons, la largeur des colonnes, les en-têtes ou les cookies.
Le document de openid-configuration découverte suit la même approche additive et compatible avec l'avenir. Pour plus d'informations sur l'analyse sécurisée de ce document, consultezPréparez-vous à apporter des modifications au document de découverte.
