Hinzufügen benutzerdefinierter Ansprüche für JWT-Zugriffstoken mit Logto zur Verbesserung deiner Autorisierung

In den vorherigen Artikeln haben wir bereits erwähnt, dass immer mehr Systeme JWT-formatierte Zugriffstoken zur Benutzerauthentifizierung und Zugriffssteuerung verwenden. Einer der wichtigen Gründe dafür ist, dass JWT nützliche Informationen wie Benutzerrollen und Berechtigungen enthalten kann. Diese Informationen können uns dabei helfen, Benutzerdaten zwischen Server und Client zu übertragen, um so die Benutzerauthentifizierung und Zugriffssteuerung zu erreichen.

Normalerweise werden die im JWT enthaltenen Informationen vom Authentifizierungsserver festgelegt. Gemäß dem OAuth 2.0-Protokoll enthält JWT in der Regel Felder wie sub (Betreff), aud (Zielgruppe) und exp (Ablaufzeit), die häufig als Ansprüche bezeichnet werden. Diese Ansprüche können helfen, die Gültigkeit des Zugriffstokens zu überprüfen.

Es gibt jedoch unzählige Szenarien, in denen JWT zur Überprüfung verwendet wird, und allgemeine JWT-Ansprüche erfüllen möglicherweise nicht immer die Anforderungen der Nutzer. Oftmals stellen sich die Leute die Frage: Da JWT einige Informationen enthalten kann, können wir ihm nicht noch einige Informationen hinzufügen, um die Autorisierung zu erleichtern?

Die Antwort ist JA, wir können benutzerdefinierte Ansprüche zu JWT hinzufügen, wie z. B. den aktuellen Benutzerbereich und das Abonnementlevel. Auf diese Weise können wir Benutzerdaten zwischen dem Client und dem Server (hier bezieht sich dies auf den Server, der verschiedene verschiedene Dienste bereitstellt, auch Dienstanbieter genannt) übertragen, um die Benutzerauthentifizierung und Zugriffssteuerung zu erreichen.

Für Standard-JWT-Ansprüche siehe RFC7519. Logto, als Lösung für Identitätsverwaltung, die sowohl Authentifizierung als auch Autorisierung unterstützt, hat die Resource und Scope Claims erweitert, um das Standard RBAC zu unterstützen. Obwohl die RBAC-Implementierung von Logto standardisiert ist, ist sie nicht einfach und flexibel genug, um allen Anwendungsfällen gerecht zu werden.

Auf dieser Grundlage hat Logto eine neue Funktion zur Anpassung von JWT-Ansprüchen eingeführt, die es den Benutzern ermöglicht, zusätzliche JWT-Ansprüche zu gestalten, sodass die Benutzerauthentifizierung und Zugriffssteuerung flexibler implementiert werden kann.

Wie funktioniert Logtos benutzerdefinierte JWT-Ansprüche?#

Du kannst zur Seite für benutzerdefinierte JWT gelangen, indem du auf die Schaltfläche "JWT-Ansprüche" in der Seitenleiste klickst.

Fangen wir an, benutzerdefinierte Ansprüche für Endbenutzer hinzuzufügen.

Im Editor auf der linken Seite kannst du deine getCustomJwtClaims Funktion anpassen. Diese Methode verfügt über drei Eingabeparameter: token, data und envVariables.

• token ist die rohe Payload des Zugriffstokens, die basierend auf den Anmeldeinformationen des aktuellen Endbenutzers und deiner Systemkonfiguration sowie den benutzerbezogenen Informationen in Logto erhalten wurde.
• data enthält alle Informationen über den Benutzer in Logto, einschließlich aller Rollen des Benutzers, Social Sign-in-Identitäten, SSO-Identitäten, Organisationsmitgliedschaften usw.
• envVariables sind die Umgebungsvariablen, die du in Logto für das aktuelle Nutzungsszenario von Zugriffstoken für Endbenutzer konfiguriert hast, wie z. B. API-Schlüssel der erforderlichen externen APIs usw.

Die Karten auf der rechten Seite können erweitert werden, um die Einführung der entsprechenden Parameter anzuzeigen. Du kannst die Umgebungsvariablen für das aktuelle Szenario ebenfalls hier festlegen.

Nachdem du die Einführungen aller Karten auf der rechten Seite gelesen hast, kannst du in den Testmodus wechseln, wo du Testdaten bearbeiten und die bearbeiteten Testdaten verwenden kannst, um zu überprüfen, ob das Verhalten des Scripts, das du im Code-Editor auf der linken Seite geschrieben hast, deinen Erwartungen entspricht.

Dies ist ein Sequenzdiagramm, das den Ausführungsprozess der Funktion getCustomJwtClaims zeigt, wenn ein Endbenutzer eine Authentifizierungsanforderung an Logto sendet und schließlich das von Logto zurückgegebene JWT-formatierte Zugriffstoken erhält.

Wenn die benutzerdefinierte JWT-Funktion nicht aktiviert ist, wird Schritt 3 in der Abbildung übersprungen und Schritt 4 wird unmittelbar nach Ende von Schritt 2 ausgeführt. Zu diesem Zeitpunkt wird Logto davon ausgehen, dass der Rückgabewert von getCustomJwtClaims ein leeres Objekt ist und dann mit den nachfolgenden Schritten fortfahren.

Verstärke deine Autorisierung mit benutzerdefinierten JWT-Ansprüchen: ein praktisches Beispiel#

Im vorherigen Abschnitt haben wir das Funktionsprinzip der benutzerdefinierten JWT von Logto vorgestellt. In diesem Teil zeigen wir dir, wie du mit benutzerdefinierten JWT-Ansprüchen von Logto die Flexibilität der Autorisierung und die Leistung des Dienstanbieters verbessern kannst, indem wir ein praktisches Beispiel verwenden.

Szenarioeinrichtung#

Johns Team hat eine AI-Assistenz-App entwickelt, die es Benutzern ermöglicht, mit AI-Robotern zu kommunizieren, um verschiedene Dienste zu erhalten.

Die AI-Roboter-Dienste sind in kostenlose und kostenpflichtige Dienste unterteilt. Zu den kostenlosen Diensten zählen spezielle Flugempfehlungen, während kostenpflichtige Dienste Aktienprognosen umfassen.

Die AI-Assistenz-App verwendet Logto zur Verwaltung aller Benutzer, die in drei Typen unterteilt sind: kostenlose Benutzer, Prepaid-Benutzer und Premium-Benutzer. Kostenlose Benutzer können nur kostenlose Dienste nutzen, Prepaid-Benutzer können alle Dienste nutzen (kostenpflichtig je nach Nutzung) und Premium-Benutzer können alle Dienste nutzen (haben jedoch Nutzungsbeschränkungen, um Missbrauch zu verhindern).

Darüber hinaus verwendet die AI-Assistenz-App Stripe zur Verwaltung von Benutzerzahlungen und hat einen eigenen Protokolldienst, um Benutzeroperationsprotokolle aufzuzeichnen.

Logto Konfigurationen#

Zuerst erstellen wir API-Ressourcen für den AI-Assistenz-App-Dienst und erstellen zwei Scopes, recommend:flight und predict:stock.

Dann erstellen wir zwei Rollen, free-user und paid-user, und ordnen die entsprechenden Scopes zu:

• Ordne die recommend:flight-Scope der free-user-Rolle zu.
• Ordne sowohl die recommend:flight- als auch die predict:stock-Scopes der paid-user-Rolle zu.

Schließlich erstellen wir drei Benutzer, free-user, prepaid-user und premium-user, und ordnen die entsprechenden Rollen zu:

• Ordne die free-user-Rolle dem Benutzer free-user zu.
• Ordne die paid-user-Rolle den Benutzern prepaid-user und premium-user zu.

Wie in der folgenden Abbildung dargestellt, hoffen wir, um die zur Umsetzung der oben beschriebenen Szenario erforderlichen Autorisierungsinformationen zu erhalten, die roles, balance und numOfCallsToday Informationen des aktuell angemeldeten Benutzers im JWT zu erfassen. Bei der Überprüfung des Zugriffstokens in der AI-Assistenz-App können diese Informationen verwendet werden, um die Berechtigungsverifizierung schnell durchzuführen.

Nach der Konfiguration der envVariables implementieren wir die getCustomJwtClaims Funktion und klicken auf die Schaltfläche "Test ausführen", um das Ergebnis der zusätzlichen JWT-Ansprüche basierend auf den aktuellen Testdaten zu sehen.

Da wir keine Testdaten für data.user.roles konfiguriert haben, ist roles im Ergebnis ein leeres Array.

Überprüfe, ob die benutzerdefinierte JWT-Funktion greift#

Gemäß der oben genannten Logto-Konfiguration erhielten wir die entsprechenden Ergebnisse im Test. Als Nächstes werden wir die von Logto bereitgestellte Beispiel-App verwenden, um zu überprüfen, ob unser benutzerdefinierter JWT wirksam ist. Finde das SDK, mit dem du vertraut bist, unter Logto SDKs und implementiere eine Beispiel-App gemäß der Dokumentation und dem entsprechenden GitHub-Repo.

Basierend auf der von uns beschriebenen Konfiguration, nehmen wir als Beispiel das React SDK, müssen wir die entsprechende Konfiguration in LogtoConfig aktualisieren:

Nachdem sich der Benutzer free_user bei der Beispiel-App angemeldet hat, die die AI-Assistenz-App simuliert, können wir die roles, balance, numOfCallsToday, isPaidUser und isPremiumUser Informationen, die wir hinzugefügt haben, durch Ansehen des Payload-Teils des JWT-Zugriffstokens sehen.

Die Werte von balance, numOfCallsToday, isPaidUser und isPremiumUser stimmen mit dem vorherigen Test überein, und roles ist gleich ["free-user"]. Dies liegt daran, dass im tatsächlichen Anmeldevorgang des Endbenutzers alle zugänglichen Daten des Benutzers abgefragt und entsprechend verarbeitet werden.

Für Premium-Benutzer können wir sehen, dass roles ["paid-user"] ist und sowohl isPaidUser als auch isPremiumUser true sind.

Aktualisiere das Autorisierungslogik des Dienstanbieters#

In den vorherigen Schritten haben wir benutzerdefinierte Ansprüche basierend auf den geschäftlichen Anforderungen dem Zugriffstoken des Benutzers hinzugefügt. Als Nächstes können wir diese Ansprüche verwenden, um die Autorisierungsverifizierung schnell durchzuführen.

Hier stellen wir die Logik von Logto zur Überprüfung von JWT-Zugriffstoken auf der API-Seite vor. Die vollständige Code-Implementierung findest du im GitHub-Repo:

Du kannst dich an der Logik von Logto zur Überprüfung von Zugriffstoken orientieren und sie nach deinen eigenen Geschäftsanforderungen anpassen. Zum Beispiel kannst du für das hier beschriebene Szenario der AI-Assistenz-App in der Funktion verifyBearerTokenFromRequest eine Verifizierungslogik für benutzerdefinierte Ansprüche wie roles, balance, numOfCallsToday, isPaidUser und isPremiumUser hinzufügen.

Das obenstehende Beispiel ist für das Szenario, in dem es sich auf die Anmeldung des Endbenutzers und den Erhalt des JWT-Zugriffstokens auswirkt. Wenn dein Anwendungsfall Maschine-zu-Maschine (M2M) ist, kannst du auch benutzerdefinierte JWT-Ansprüche für M2M-Apps separat konfigurieren.

Die Konfiguration von benutzerdefiniertem JWT für Benutzer hat keine Auswirkungen auf das Ergebnis, wenn M2M-Apps Zugriffstoken abrufen, und umgekehrt.

Aufgrund der allgemeinen Natur von M2M-Verbindungen bietet Logto derzeit keine Funktion der getCustomJwtClaims Methode für M2M-Apps, die interne Daten von Logto akzeptiert. In anderen Aspekten ist die Konfigurationsmethode für benutzerdefinierte JWT-Ansprüche für M2M-Apps jedoch die gleiche wie die für Benutzer-Apps. Dieser Artikel wird darauf nicht näher eingehen. Du kannst Logtos benutzerdefinierte JWT-Funktion nutzen, um loszulegen.

Warum benutzerdefinierte JWT-Ansprüche verwenden?#

Wir haben das Szenario der AI-Assistenz-App für John und gezeigt, wie Logtos benutzerdefinierte JWT-Funktion verwendet wird, um flexiblere Autorisierungsverifizierungen durchzuführen. In diesem Prozess können wir die Vorteile der benutzerdefinierten JWT-Funktion sehen:

1. Ohne die benutzerdefinierte JWT-Funktion müsste der Nutzer jedes Mal, wenn er die Berechtigungen überprüft, eine externe API anfragen (wie es in getCustomJwtClaims der Fall ist). Für den Dienstanbieter, der diese API bereitstellt, könnte dies eine zusätzliche Last bedeuten. Mit der benutzerdefinierten JWT-Funktion können diese Informationen direkt in das JWT eingebracht werden, wodurch häufige Anfragen an eine externe API reduziert werden.
2. Für Dienstanbieter kann die benutzerdefinierte JWT-Funktion ihnen helfen, Benutzerberechtigungen schneller zu überprüfen, besonders, wenn der Client häufig den Dienstanbieter aufruft, wodurch die Dienstleistung verbessert wird.
3. Die benutzerdefinierte JWT-Funktion kann dir helfen, zusätzliche Autorisierungsinformationen schnell zu implementieren, die im Geschäft erforderlich sind. Da JWT eigenständig ist und verschlüsselt werden kann, ist es schwierig zu fälschen, sodass diese Informationen sicher zwischen dem Client und dem Dienstanbieter übertragen werden können.

Gleichzeitig, da getCustomJwtClaims jedes Mal ausgeführt wird, wenn ein Benutzer auf Logto ein Zugriffstoken ausstellen muss, sollte vermieden werden, übermäßig komplexe Logiken und externe API-Anfragen mit hohem Bandbreitenbedarf auszuführen. Andernfalls könnte es für den Endbenutzer zu lange dauern, auf das Ergebnis von getCustomJwtClaims im Anmeldevorgang zu warten. Wenn deine getCustomJwtClaims ein leeres Objekt zurückgibt, empfehlen wir dringend, diese Konfiguration vorübergehend zu löschen, bis du sie tatsächlich benötigst.

Schlussfolgerung#

In diesem Artikel hat Logto das grundlegende JWT-Zugriffstoken erweitert und die Funktion zusätzlicher JWT-Ansprüche ausgebaut, um es den Nutzern zu ermöglichen, zusätzliche Endbenutzerinformationen in das JWT-Zugriffstoken gemäß ihren geschäftlichen Anforderungen einzufügen, sodass die Benutzerberechtigungen nach der Anmeldung schnell überprüft werden können.

Wir bieten das Szenario von Johns AI-Assistenz-App an und demonstrieren, wie die benutzerdefinierte JWT-Funktion von Logto verwendet wird, um flexiblere Autorisierungsverifizierungen durchzuführen. Wir weisen auch auf einige wichtige Punkte bei der Nutzung benutzerdefinierter JWT hin. In Kombination mit tatsächlichen Geschäftsszenarien können Benutzer verschiedene benutzerbezogene Informationen in das JWT-Zugriffstoken gemäß ihren geschäftlichen Anforderungen einfügen, sodass der Dienstanbieter die Benutzerberechtigungen schnell überprüfen kann.