Sollten Zugriffsberechtigungen und Rollen in der Nutzlast von JWT enthalten sein?


9

Sollten Informationen zu den Berechtigungen und Rollen des Clients in JWT enthalten sein?

Solche Informationen im JWT-Token zu haben, ist sehr hilfreich, da es jedes Mal, wenn ein gültiges Token eingeht, einfacher ist, die Informationen über die Berechtigung des Benutzers zu extrahieren, und es nicht erforderlich ist, die Datenbank für dasselbe aufzurufen. Aber ist es ein Sicherheitsproblem, solche Informationen in die Datenbank aufzunehmen und sie nicht doppelt zu überprüfen?

Oder,

Informationen wie die oben genannten sollten niemals Teil von JWT sein, und nur die Datenbank sollte zur Überprüfung der Zugriffsrollen und Berechtigungen eines Benutzers verwendet werden.

Antworten:


7

Der Zweck des Einfügens von Ansprüchen in das Token besteht darin, dass Sie diese Kommunikation zwischen der Ressource und dem Authentifizierungsanbieter nicht benötigen.

Die Ressource kann einfach überprüfen, ob das Token eine gültige Signatur hat, und dem Inhalt vertrauen.

Angenommen, der private Schlüssel ist für den Authentifizierungsserver privat, dann sind Sie gut. Einige Anbieter ändern ihren Schlüssel, um das Risiko zu verringern.

Wenn Sie darüber nachdenken, wenn die Ressource einen Rückruf an den Authentifizierungsserver getätigt hat, um die Ansprüche zu erhalten. Dann wird im Wesentlichen sichergestellt, dass über ähnliche Vertrauensmethoden mit dem richtigen Server gesprochen wird.


Vielen Dank für eine schöne Antwort. Darf ich mehr darüber wissen, was Sie mit Ihrer Aussage gemeint haben: "Einige Anbieter ändern ihren Schlüssel, um das Risiko zu minimieren." ?
Anshul Sahni

1
Anstatt einen festen Signaturschlüssel zu haben, wird der Authentifizierungsanbieter ihn von Zeit zu Zeit ändern und einen Endpunkt für Ressourcenserver bereitstellen, auf dem die öffentliche Hälfte heruntergeladen werden kann. Die Ressourcen müssen von Zeit zu Zeit den Authentifizierungsserver anrufen, jedoch nicht einmal pro Anfrage
Ewan

Daher sind alle Token jedes Mal ungültig, wenn die Schlüsselsignatur vom Dienst geändert wird
Anshul Sahni,

1
Normalerweise haben sie mehr als einen möglichen Schlüssel, so dass Token im Flug nicht ungültig werden. Das Token enthält eine 'Schlüssel-ID', um der Ressource mitzuteilen, welche verwendet werden soll
Ewan

Das einzige, was ich hier vermisse, ist, wie ich vorgehen soll, wenn die Daten im JWT ungültig sind. Angenommen, die Rollen wurden auf der Serverseite geändert, aber der Client verfügt weiterhin über das Token mit allen Rollen. Sie müssen in der Lage sein, Token auf der Serverseite zu widerrufen, damit diese Token mit veralteten Informationen nicht mehr gültig sind und für weitere Anforderungen verwendet werden können. Dies steht im Einklang mit dem, was Ewans aus dem einen oder anderen Grund vorschlägt (damit der Server das Token widerrufen kann).
Laiv

1

Wenn alle Ihre Systeme eine zentrale Rollen- und Berechtigungsdatenbank verwenden, können Sie meiner Erfahrung nach all das zu JWT hinzufügen.

Dieser Ansatz funktioniert jedoch möglicherweise nicht gut in SSO-Szenarien, wenn der Authentifizierungsserver selbst keinerlei Ahnung von dem Zielsystem hat, das das Token empfängt und ihm vertraut.

Die Rollen und Berechtigungen des Benutzers liegen vollständig beim Empfänger des JWT-Tokens. Dies gilt insbesondere dann, wenn Sie die SSO-Authentifizierung mit JWT in einige Legacy-Systeme integrieren, deren Berechtigungssubsystem bereits vorhanden ist und daher nur ein Anspruch erforderlich ist, um in JWT vorhanden zu sein - der Anspruch auf Benutzeridentität.


Da stimme ich zu. Benutzerberechtigungen sollten nicht Teil von jwt sein, insbesondere in SSO, da der IDP nicht weiß, mit welchen anderen Diensten dieser Benutzer jwt sprechen wird. Stattdessen sollte die Ressource den Autorisierungsteil implementieren, sobald die Identität für den Benutzer bestätigt wurde
Manish Rawat

Ich stimme auch zu, dass Berechtigungsansprüche in JWTs keine gute Idee sind, die über eine einfache monolithische API hinausgeht. Ich habe einen Blog-Beitrag darüber geschrieben: sdoxsee.github.io/blog/2020/01/06/…
sdoxsee
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.