Voeg aangepaste claims toe voor JWT-toegangstokens met Logto om je autorisatie te verbeteren

In eerdere artikelen hebben we vermeld dat steeds meer systemen JWT-formaat toegangstokens gebruiken voor gebruikersauthenticatie en toegangscontrole. Een van de belangrijke redenen hiervoor is dat JWT nuttige informatie kan bevatten, zoals gebruikersrollen en permissies. Deze informatie kan ons helpen gebruikersidentiteitsinformatie tussen de server en client over te dragen, waardoor gebruikersauthenticatie en toegangscontrole mogelijk worden.

Gewoonlijk wordt de informatie die in JWT is opgenomen bepaald door de authenticatieserver. Volgens het OAuth 2.0-protocol bevat JWT meestal velden zoals sub (onderwerp), aud (publiek) en exp (vervaltijd), die meestal claims worden genoemd. Deze claims kunnen helpen de geldigheid van het toegangstoken te verifiëren.

Er zijn echter talloze scenario's waarin JWT wordt gebruikt voor verificatie, en de gebruikelijke JWT-claims voldoen mogelijk vaak niet aan de behoeften van gebruikers. Mensen denken vaak dat, aangezien JWT enige informatie kan bevatten, we er wat informatie aan kunnen toevoegen om autorisatie gemakkelijker te maken?

Het antwoord is JA, we kunnen aangepaste claims toevoegen aan JWT, zoals het huidige gebruikersbereik en abonnementsniveau. Op deze manier kunnen we gebruikersidentiteitsinformatie tussen de client en de server (hier verwijst naar de server die verschillende diensten aanbiedt, ook wel serviceprovider genoemd) overdragen om gebruikersauthenticatie en toegangscontrole te realiseren.

Voor standaard JWT-claims, zie RFC7519. Logto, als een identiteit oplossing die zowel authenticatie als autorisatie ondersteunt, heeft op deze basis de claims resource en scope uitgebreid om standaard RBAC te ondersteunen. Hoewel Logto's RBAC-implementatie standaard is, is het niet simpel en flexibel genoeg om in alle gebruiksscenario's te passen.

Op basis hiervan heeft Logto een nieuwe functie gelanceerd voor het aanpassen van JWT-claims, waarmee gebruikers extra JWT-claims kunnen aanpassen, zodat gebruikersauthenticatie en toegangscontrole flexibeler kunnen worden geïmplementeerd.

Hoe werken Logto aangepaste JWT-claims?#

Je kunt naar de pagina voor het weergeven van aangepaste JWT gaan door op de knop "JWT-claims" in de zijbalk te klikken.

Laten we beginnen met het toevoegen van aangepaste claims voor eindgebruikers.

In de editor aan de linkerkant kun je je getCustomJwtClaims-functie aanpassen. Deze methode heeft drie invoerparameters: token, data en envVariables.

• token is de ruwe toegangstoken payload verkregen op basis van de huidige eindgebruikersgegevens en je systeemconfiguratie, en de toegang gerelateerde informatie van de gebruiker in Logto
• data is alle informatie over de gebruiker in Logto, inclusief alle rollen van de gebruiker, identiteiten voor sociale aanmelding, SSO-identiteiten, lidmaatschappen van organisaties, etc.
• envVariables zijn de omgevingsvariabelen die je hebt geconfigureerd in Logto voor het huidige eindgebruikers toegangstokenscenario, zoals API-sleutel(s) van de vereiste externe API's, etc.

De kaarten aan de rechterkant kunnen worden uitgebreid om de introductie van de overeenkomstige parameters te tonen, en je kunt hier ook de omgevingsvariabelen voor het huidige scenario instellen.

Na het lezen van de introducties van alle kaarten aan de rechterkant, kun je overschakelen naar de testmodus, waar je testgegevens kunt bewerken en de bewerkte testgegevens kunt gebruiken om te controleren of het gedrag van het script dat je in de code-editor aan de linkerkant hebt geschreven aan je verwachtingen voldoet.

Dit is een sequentiediagram dat het uitvoeringsproces van de getCustomJwtClaims-functie laat zien wanneer een eindgebruiker een authenticatieverzoek naar Logto initieert en uiteindelijk het JWT-formaat toegangstoken ontvangt dat door Logto wordt geretourneerd.

Als de functie van aangepaste JWT niet is ingeschakeld, wordt stap 3 in de afbeelding overgeslagen en wordt stap 4 direct uitgevoerd nadat stap 2 is beëindigd. Op dat moment neemt Logto aan dat de retourwaarde van getCustomJwtClaims een leeg object is en vervolgens doorgaat met het doorlopen van de volgende stappen.

Verhoog je autorisatie met aangepaste JWT-claims: een praktisch voorbeeld#

In de vorige sectie hebben we het werkingsprincipe van de Logto aangepaste JWT geïntroduceerd. In dit deel zullen we je laten zien hoe je Logto aangepaste JWT-claims kunt gebruiken om de flexibiliteit van autorisatie en de prestaties van de serviceprovider te verbeteren aan de hand van een praktijkvoorbeeld.

Scenario-instelling#

Johns team heeft een AI-assistent-app ontwikkeld waarmee gebruikers in gesprek kunnen gaan met AI-robots om verschillende diensten te verkrijgen.

De AI-robotdiensten zijn onderverdeeld in gratis en betaalde diensten. Gratis diensten omvatten specifieke vlucht aanbevelingen, terwijl betaalde diensten onder meer aandelenvoorspellingen omvatten.

De AI Assistent App maakt gebruik van Logto om alle gebruikers te beheren, die zijn onderverdeeld in drie typen: gratis gebruikers, vooraf betaalde gebruikers en premium gebruikers. Gratis gebruikers kunnen alleen gratis diensten gebruiken, vooraf betaalde gebruikers kunnen alle diensten gebruiken (afgerekend per gebruik), en premium gebruikers kunnen alle diensten gebruiken (maar hebben limieten om misbruik te voorkomen).

Bovendien maakt de AI Assistent App gebruik van Stripe om gebruikersbetalingen te beheren en heeft het een eigen logservice om gebruikerslogboeken bij te houden.

Logto configuraties#

We maken eerst API-bronnen voor de AI Assistent App service en creëren twee scopes, recommend:flight en predict:stock.

Daarna creëren we twee rollen, free-user en paid-user, en wijzen we de overeenkomende scopes toe:

• Wijs de recommend:flight scope toe aan de free-user rol.
• Wijs zowel recommend:flight als predict:stock scopes toe aan de paid-user rol.

Ten slotte maken we drie gebruikers, free-user, prepaid-user en premium-user, en wijzen we de overeenkomende rollen toe:

• Wijs de free-user rol toe aan gebruiker free-user.
• Wijs de paid-user rol toe aan gebruikers prepaid-user en premium-user.

Zoals weergegeven in de volgende figuur, om de autorisatie-informatie te implementeren die vereist is voor het hierboven beschreven scenario, hopen we de rollen, saldo en numOfCallsToday informatie van de momenteel ingelogde gebruiker in de JWT op te nemen. Bij het verifiëren van het toegangstoken in de AI Assistent App kan deze informatie worden gebruikt om snel permissie verificatie uit te voeren.

Na het configureren van de envVariables, implementeren we de functie getCustomJwtClaims en klikken we op de knop "Run test" om het resultaat van de extra JWT-claims te zien op basis van de huidige testgegevens.

Aangezien we de testgegevens voor data.user.roles niet hebben geconfigureerd, is de rollen die in het resultaat wordt weergegeven een lege array.

Controleer of de aangepaste JWT-functie werkt#

Volgens de bovenstaande Logto-configuratie hebben we de overeenkomstige resultaten in de test gekregen. Vervolgens zullen we de voorbeeldapp gebruiken die door Logto is geleverd om te verifiëren of onze aangepaste JWT effectief is. Zoek de SDK die je bekend vindt op Logto SDKs en implementeer een voorbeeldapp volgens de documentatie en de overeenkomstige GitHub-repo.

Op basis van de configuratie die we hierboven hebben beschreven, nemen we de React SDK als voorbeeld, we moeten de overeenkomstige configuratie in LogtoConfig bijwerken:

Nadat de gebruiker free_user heeft aangemeld bij de voorbeeldapp die de AI Assistant App simuleert, kunnen we de rollen, saldo, numOfCallsToday, isPaidUser en isPremiumUser informatie die we hebben toegevoegd zien door het payloadgedeelte van het JWT-toegangstoken te bekijken.

De waarden van saldo, numOfCallsToday, isPaidUser en isPremiumUser zijn consistent met de vorige test, en rollen is gelijk aan ["free-user"]. Dit komt omdat we in het daadwerkelijke eindgebruikers inlogproces alle toegankelijke gegevens van de gebruiker zullen verkrijgen en dienovereenkomstig verwerken.

Voor premium gebruikers kunnen we zien dat rollen ["paid-user"] is en dat zowel isPaidUser als isPremiumUser true zijn.

Update serviceprovider autorisatielogica#

In de vorige stappen hebben we aangepaste claims toegevoegd op basis van zakelijke behoeften aan het gebruikers toegangstoken. Vervolgens kunnen we deze claims gebruiken om snel autorisatie verificatie uit te voeren.

Hier bieden we de logica van Logto voor het verifiëren van JWT toegangstokens aan de API-kant. De volledige code implementatie is te vinden in de GitHub-repo:

Je kunt verwijzen naar de logica van Logto API voor het verifiëren van toegangstokens en deze aanpassen volgens je eigen zakelijke logica. Bijvoorbeeld, voor het AI Assistent App-scenario dat hier wordt beschreven, kun je verificatielogica toevoegen voor aangepaste claims zoals rollen, saldo, numOfCallsToday, isPaidUser en isPremiumUser in de verifyBearerTokenFromRequest functie.

Het bovenstaande voorbeeld is voor het scenario waarin het effect heeft op de eindgebruikersinlog en het verkrijgen van het JWT toegangstoken. Als je use case machine-to-machine (M2M) is, kun je ook apart aangepaste JWT-claims configureren voor M2M-apps.

Het configureren van aangepaste JWT voor gebruikers zal het resultaat van M2M-apps bij het verkrijgen van toegangstokens niet beïnvloeden, en vice versa.

Vanwege de algemeenheid van M2M-verbindingen biedt Logto momenteel niet de functie van de getCustomJwtClaims-methode van M2M-apps om interne gegevens van Logto te accepteren. In andere opzichten is de configuratiemethode van aangepaste JWT voor M2M-apps hetzelfde als die van gebruikersapps. Dit artikel zal daar niet verder op ingaan. Je kunt Logto's aangepaste JWT-functie gebruiken om te beginnen.

Waarom aangepaste JWT-claims gebruiken?#

We hebben het AI Assistent Apps-scenario voor John en hoe je met de Custom JWT-functie van Logto een flexibelere autorisatie verificatie kunt bereiken. In dit proces zien we de voordelen van de Custom JWT-functie:

1. Zonder de Custom JWT-functie moeten gebruikers elke keer dat ze permissies controleren een externe API aanvragen (zoals je doet in getCustomJwtClaims). Voor de serviceprovider die deze API biedt, kan dit een extra belasting vormen. Met de Custom JWT-functie kunnen deze informatie direct in de JWT worden geplaatst, waardoor de frequente oproepen naar de externe API worden verminderd.
2. Voor serviceproviders kan de Custom JWT-functie hen helpen gebruikersrechten sneller te verifiëren, vooral wanneer de client vaak de serviceprovider oproept, wat de serviceprestaties verbetert.
3. De Custom JWT-functie kan je helpen snel extra autorisatie-informatie te implementeren die vereist is door de business, en de informatie kan op een veilige manier tussen de client en de serviceprovider worden doorgegeven, aangezien JWT zichzelf bevat en kan worden versleuteld zodat het moeilijk te vervalsen is.

Tegelijkertijd, aangezien getCustomJwtClaims elke keer wordt uitgevoerd wanneer een gebruiker Logto nodig heeft om een toegangstoken uit te geven, is het noodzakelijk te voorkomen dat er te complexe logica en externe API-verzoeken met hoge bandbreedte-eisen worden uitgevoerd. Anders kan het te lang duren voor eindgebruikers om te wachten op het resultaat van getCustomJwtClaims tijdens het aanmeldingsproces. Als je getCustomJwtClaims een leeg object retourneert, raden we sterk aan om dit configuratie-item tijdelijk te verwijderen totdat je het daadwerkelijk nodig hebt.

Conclusie#

In dit artikel heeft Logto het basis JWT toegangstoken uitgebreid en de functie van extra JWT-claims uitgebreid om gebruikers in staat te stellen extra eindgebruikersinformatie in het JWT toegangstoken te plaatsen op basis van hun zakelijke behoeften, zodat na de aanmelding van de gebruiker de gebruikersrechten snel kunnen worden geverifieerd.

We bieden het scenario van Johns AI Assistent App en laten zien hoe je de Custom JWT-functie van Logto kunt gebruiken om een flexibelere autorisatie verificatie te bereiken. We wijzen ook enkele belangrijke punten bij het gebruik van aangepaste JWT aan. In combinatie met feitelijke zakelijke scenario's kunnen gebruikers verschillende gebruikersgerelateerde informatie in het JWT toegangstoken plaatsen volgens hun zakelijke behoeften, zodat de serviceprovider snel de gebruikersrechten kan verifiëren.