6. Privacy Considerations (Datenschutzerwägungen)
Da JWT-Zugriffstoken Informationen nach Wert transportieren, wird es nun für Clients und möglicherweise sogar Endbenutzer möglich, direkt in die Claim-Sammlung unverschlüsselter Token zu schauen.
Der Client darf (MUST NOT) den Inhalt des Zugriffstokens inspizieren: Der Autorisierungsserver und der Ressourcenserver könnten jederzeit entscheiden, das Token-Format zu ändern (z.B. durch Wechsel von diesem Profil zu opaken Token); daher würde jede Logik im Client, die sich auf die Fähigkeit verlässt, den Inhalt des Zugriffstokens zu lesen, ohne Möglichkeit zur Wiederherstellung brechen. Das OAuth 2.0-Framework geht davon aus, dass Zugriffstoken von Clients als opak behandelt werden. Administratoren von Autorisierungsservern sollten auch berücksichtigen, dass der Inhalt eines Zugriffstokens für den Client sichtbar ist. Wann immer der Zugriff des Clients auf den Inhalt des Zugriffstokens Datenschutzprobleme für ein gegebenes Szenario darstellt, muss der Autorisierungsserver explizite Schritte unternehmen, um diese zu verhindern.
In Szenarien, in denen JWT-Zugriffstoken für den Endbenutzer zugänglich sind, sollte bewertet werden, ob auf die Informationen ohne Datenschutzverletzungen zugegriffen werden kann (z.B. wenn ein Endbenutzer einfach auf seine eigenen persönlichen Informationen zugreift) oder ob Schritte unternommen werden müssen, um die Vertraulichkeit zu gewährleisten.
Mögliche Maßnahmen zur Verhinderung von Informationslecks an Clients und Endbenutzer umfassen: Verschlüsselung des Zugriffstokens, Verschlüsselung der sensiblen Claims, Weglassen der sensiblen Claims oder Nichtverwendung dieses Profils und Rückgriff auf opake Zugriffstoken.
In jedem Szenario wird der Inhalt des JWT-Zugriffstokens letztendlich für den Ressourcenserver zugänglich sein. Es ist wichtig zu bewerten, ob der Ressourcenserver den entsprechenden Anspruch auf Zugriff auf alle in Form von Claims erhaltenen Inhalte erlangt hat, zum Beispiel durch Benutzereinwilligung in irgendeiner Form, Richtlinien und Vereinbarungen mit der Organisation, die die Autorisierungsserver betreibt, usw. Beispielsweise möchte ein Benutzer möglicherweise nicht zustimmen, dem betreffenden Ressourcenserver Informationen über eine der nicht obligatorischen Claims zu gewähren, die in Abschnitt 2 (und seinen Unterabschnitten) aufgezählt sind.
Dieses Profil schreibt das Vorhandensein des "sub"-Claims in jedem JWT-Zugriffstoken vor, was es Ressourcenservern ermöglicht, sich auf diese Informationen zu verlassen, um eingehende Anfragen mit lokal gespeicherten Daten für den authentifizierten Principal zu korrelieren. Obwohl die Fähigkeit, Anfragen zu korrelieren, in vielen Szenarien design-bedingt erforderlich sein kann, gibt es Szenarien, in denen der Autorisierungsserver eine Korrelation verhindern möchte. Der "sub"-Claim sollte von Autorisierungsservern gemäß einer Datenschutz-Folgenabschätzung ausgefüllt werden. Wenn beispielsweise eine Lösung erfordert, dass die Verfolgung der Aktivitäten des Principals über mehrere Ressourcenserver hinweg verhindert wird, sollte der Autorisierungsserver sicherstellen, dass JWT-Zugriffstoken, die für verschiedene Ressourcenserver bestimmt sind, unterschiedliche "sub"-Werte haben, die im Falle einer Absprache zwischen Ressourcenservern nicht korreliert werden können. Ähnlich sollte der Autorisierungsserver, wenn eine Lösung erfordert, dass ein Ressourcenserver die Aktivität des Principals innerhalb der Ressource selbst nicht korrelieren kann, für jedes ausgestellte JWT-Zugriffstoken unterschiedliche "sub"-Werte zuweisen. Der Client sollte wiederum für jeden Aufruf an den Ressourcenserver ein neues JWT-Zugriffstoken erhalten, um sicherzustellen, dass der Ressourcenserver bei jedem Aufruf unterschiedliche "sub"- und "jti"-Werte erhält und so eine Korrelation zwischen verschiedenen Anfragen verhindert wird.