Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.
Analysieren Sie Benutzerpool-Token sicher
Der Anspruchssatz eines Amazon Cognito Cognito-Tokens ist nicht festgelegt. Die Ansprüche, die Ihr Token enthält, hängen vom Authentifizierungsablauf, der Gruppenmitgliedschaft des Benutzers und dem Identitätsanbieter sowie von den Funktionen ab, die Sie in Ihrem Benutzerpool aktivieren. Amazon Cognito fügt im Laufe der Zeit additiv neue Ansprüche hinzu: Es führt neue Schlüssel ein, aber es werden die in diesem Leitfaden dokumentierten Ansprüche weder umbenannt, noch deren Typ geändert oder entfernt. Diese Regeln gelten sowohl für ID-Token als auch für Zugriffstoken.
Schreiben Sie keinen eigenen Token-Parser. Verwenden Sie eine JSON-Webtoken-Bibliothek (JWT) und einen JSON-Parser, die auch dann funktionieren, wenn das Token wächst. Die beiden Regeln, die fast jeden Verstoß in der realen Welt verhindern, sind die ersten beiden unten: Tolerieren Sie Behauptungen, die Sie nicht erkennen, und treffen Sie die richtigen Annahmen über Art und Kardinalität jeder Behauptung, die Sie lesen.
- Ignoriere Behauptungen, die du nicht anerkennst
-
Lesen Sie die Ansprüche, die Ihre Bewerbung benötigt, und lassen Sie den Rest in Ruhe. Lehnen Sie es nicht ab, scheitern Sie nicht und geben Sie keinen Fehler aus, wenn ein Token einen Anspruch enthält, der nicht in diesem Leitfaden aufgeführt ist. Neue Ansprüche werden additiv hinzugefügt, und ein Token, das einen Anspruch enthält, der nicht in der Liste aufgeführt ist, ist weiterhin gültig.
- Lesen Sie jeden Anspruch in seiner dokumentierten Form
-
Ein JSON-Parser identifiziert den primitiven Typ jedes Werts anhand der JSON-Datei selbst. Das Risiko liegt also in den Annahmen, die Ihr Code dann über diesen Wert trifft. Behandeln Sie jeden Anspruch nach dem Typ und der Kardinalität, die in diesem Leitfaden beschrieben sind. Ein Anspruch, der als Array dokumentiert ist, ist immer ein Array, auch wenn er derzeit einen einzelnen Wert enthält. Reduzieren Sie es nicht zu einer Zeichenfolge. Zum Beispiel
identitiessindcognito:groups,cognito:roles, und immer Arrays. Das gleiche Prinzip gilt für Ansprüche, die durch andere Spezifikationen definiert sind. Falls vorhandenamr, handelt es sich beispielsweise um ein Array von Zeichenketten, wie es in RFC 8176auf der IETF-Website definiert ist. Lesen Sie es also in diesem Typ. - Überprüfen Sie die Anspruchsformate nicht
-
Bestätigen Sie, was die Spezifikation für einen Anspruch erfordert, und nicht mehr. Beispielsweise
subhandelt es sich um eine eindeutige Zeichenfolge, die jedoch nicht garantiert in einem bestimmten UUID-Format vorliegt. Einige Werte in benutzerdefinierten Ansprüchen, z. B.identitieswerden als Zeichenketten serialisiert und nicht als JSON-Boolesche Werte oder Zahlen, und für undurchsichtige Werte kann nicht garantiert werden, dass sie eine bestimmte Länge haben. Die Einführung eines strengeren Formats als in der Dokumentation angegeben führt dazu, dass gültige Token fehlschlagen. - Gehen Sie nicht von der Anzahl der Anträge oder deren Reihenfolge aus
-
Die Ansprüche in einem Token können in beliebiger Reihenfolge erscheinen, und die Anzahl kann sich zwischen den Tokens und im Laufe der Zeit ändern. Adressieren Sie jeden Anspruch nach Namen und nicht nach Position, und analysieren Sie das Token als allgemeines JSON-Objekt und nicht als feste Struktur.
- Budget für das Wachstum der Token-Größe
-
Da der Anspruchssatz wächst, nimmt auch die Gesamtgröße des Tokens zu. Gehen Sie nicht von einer festen oder maximalen Tokengröße in Bezug auf Puffer, Spaltenbreiten, Überschriften oder Cookies aus.
Das openid-configuration Discovery-Dokument folgt demselben additiven, zukunftskompatiblen Ansatz. Weitere Informationen zum sicheren Analysieren dieses Dokuments finden Sie unter. Bereiten Sie sich auf Änderungen am Discovery-Dokument vor
