Lägg till anpassade fordringar för JWT-åtkomsttoken med Logto för att förbättra din autentisering

I tidigare artiklar nämnde vi att fler och fler system använder åtkomsttoken i JWT-format för användarauktorisering och åtkomstkontroll. En av de viktiga anledningarna till detta är att JWT kan innehålla användbar information, såsom användarroller och behörigheter. Denna information kan hjälpa oss att överföra användarens identitetsinformation mellan server och klient, och därmed uppnå användarauktorisering och åtkomstkontroll.

Vanligtvis bestäms informationen som ingår i JWT av autentiseringsservern. Enligt OAuth 2.0-protokollet innehåller JWT vanligtvis fält som sub (ämne), aud (målgrupp) och exp (utgångstid), som vanligtvis kallas fordringar. Dessa fordringar kan hjälpa till att verifiera giltigheten av åtkomsttoken.

Det finns dock otaliga scenarier där JWT används för verifiering, och vanliga JWT-fordringar kanske ofta inte uppfyller användarbehoven. Folk tänker ofta att eftersom JWT kan innehålla viss information, kan vi lägga till viss information för att göra auktoriseringen enklare?

Svaret är JA, vi kan lägga till anpassade fordringar till JWT, såsom den aktuella användarens räckvidd och abonnemangsnivå. På så sätt kan vi överföra användarens identitetsinformation mellan klienten och servern (här avses servern som tillhandahåller olika tjänster, även kallad tjänsteleverantör) för att uppnå användarauktorisering och åtkomstkontroll.

För standard-JWT-fordringar, vänligen hänvisa till RFC7519. Logto, som en identitetslösning som stödjer både autentisering och auktorisering, har utökat resurs- och räckviddsfordringarna på denna grund för att stödja standard RBAC. Även om Logtos RBAC-implementering är standard är den inte tillräckligt enkel och flexibel för att passa alla användningsfall.

Baserat på detta har Logto lanserat en ny funktion för att anpassa JWT-fordringar, vilket gör att användare kan anpassa ytterligare JWT-fordringar så att användarauktorisering och åtkomstkontroll kan implementeras mer flexibelt.

Hur fungerar Logtos anpassade JWT-fordringar?#

Du kan komma till sidan för anpassade JWT-fordringar genom att klicka på "JWT-fordringar"-knappen i sidofältet.

Låt oss börja med att lägga till anpassade fordringar för slutanvändare.

I redigeraren till vänster kan du anpassa din getCustomJwtClaims-funktion. Denna metod har tre inmatningsparametrar: token, data och envVariables.

• token är den råa åtkomsttokenens payload som erhålls baserat på den aktuella slutanvändarens referenser och din systemkonfiguration, samt användarens åtkomstrelaterade information i Logto
• data är all information om användaren i Logto, inklusive alla användarens roller, social inloggningsidentiteter, SSO-identiteter, organisationsmedlemskap, etc.
• envVariables är de miljövariabler du konfigurerade i Logto för den aktuella slutanvändarens åtkomsttokens användningsscenario, såsom API-nyckel(-ar) för de nödvändiga externa API:erna, etc.

Korterna till höger kan utökas för att visa introduktionen av de motsvarande parametrarna, och du kan också ställa in miljövariablerna för det aktuella scenariot här.

Efter att ha läst introduktionerna av alla korten till höger kan du byta till testläge, där du kan redigera testdata och använda de redigerade testdata för att kontrollera om beteendet hos skriptet du skrev i kodedigeraren till vänster uppfyller dina förväntningar.

Detta är ett sekvensdiagram som visar exekveringsprocessen för getCustomJwtClaims-funktionen när en slutanvändare initierar en autentiseringsförfrågan till Logto och slutligen får JWT-formatets åtkomsttoken som returneras av Logto.

Om funktionen Anpassad JWT inte är aktiverad, kommer steg 3 i figuren att hoppas över och steg 4 kommer att utföras direkt efter att steg 2 har avslutats. Vid denna tidpunkt kommer Logto att anta returvärdet av getCustomJwtClaims till att vara ett tomt objekt och sedan fortsätta att gå igenom efterföljande steg.

Stärk din auktorisering med anpassade JWT-fordringar: ett praktiskt exempel#

I föregående avsnitt introducerade vi arbetsprincipen för Logtos anpassade JWT. I denna del ska vi visa dig hur du använder Logtos anpassade JWT-fordringar för att förbättra flexibiliteten i auktorisering och prestanda för tjänsteleverantören genom ett verkligt exempel.

Scenario#

Johns team utvecklade en AI Assistant-app som låter användare konversera med AI-robotar för att få olika tjänster.

AI-robotens tjänster är uppdelade i gratis och betalda tjänster. Gratistjänster inkluderar specialerbjudanden på flygbiljetter, medan betalda tjänster inkluderar aktieprognoser.

AI Assistant-appen använder Logto för att hantera alla användare, som är indelade i tre typer: gratianvändare, förbetalda användare och premiumanvändare. Gratianvändare kan endast använda gratistjänster, förbetalda användare kan använda alla tjänster (debiteras efter användning), och premiumanvändare kan använda alla tjänster (men har gränser för att förhindra missbruk).

Dessutom använder AI Assistant-appen Stripe för att hantera användarbetalningar och har sin egen loggningstjänst för att registrera användarens operationsloggar.

Logto-konfigurationer#

Först skapar vi API-resurser för AI Assistant-appens tjänst och skapar två scopes, recommend:flight och predict:stock.

Sedan skapar vi två roller, gratisanvändare och betalande användare, och tilldelar motsvarande scopes:

• Tilldela scope recommend:flight till gratisanvändare-rollen.
• Tilldela både recommend:flight och predict:stock scopes till betalande användare-rollen.

Slutligen skapar vi tre användare, gratisanvändare, förbetald-användare och premium-användare och tilldelar motsvarande roller:

• Tilldela gratisanvändare-rollen till användaren gratisanvändare.
• Tilldela betalande-användare-rollen till användarna förbetald-användare och premium-användare.

Som visas i följande bild hoppas vi att inkludera informationen roller, balans och numOfCallsToday för den inloggade användaren i JWT för att implementera den auktoriseringsinformation som krävs för scenariot som beskrivs ovan. När vi verifierar åtkomsttoken i AI Assistant-appen kan denna information användas för att snabbt utföra behörighetsverifiering.

Efter konfiguration av envVariables implementerar vi getCustomJwtClaims-funktionen och klickar på "Kör test"-knappen för att se resultatet av de extra JWT-fordringarna baserat på den aktuella testdata.

Eftersom vi inte har konfigurerat testdata för data.user.roles, visas roller i resultatet som en tom array.

Kontrollera om den anpassade JWT-funktionen är aktiverad#

Enligt Logto-konfigurationen ovan fick vi motsvarande resultat i testet. Nästa, vi använder ett exempel på appen som Logto har tillhandahållit för att verifiera om vår anpassade JWT är effektiv. Hitta SDK:n du är bekant med på Logto SDKs och distribuera en provapp enligt dokumentationen och motsvarande GitHub-repo.

Baserat på konfigurationen vi beskrev ovan, med React SDK som exempel, behöver vi uppdatera motsvarande konfiguration i LogtoConfig:

Efter att ha loggat in användaren gratis_användare i exempelappen som simulerar AI Assistant-appen, kan vi se informationen roller, balans, numOfCallsToday, isPaidUser och isPremiumUser som vi lade till genom att visa payload-delen av JWT-åtkomsttoken.

Värdena för balans, numOfCallsToday, isPaidUser och isPremiumUser överensstämmer med tidigare test, och roller är lika med ["gratisanvändare"]. Detta beror på att vi under den faktiska slutanvändarinloggningsprocessen får all tillgänglig data om användaren och behandlar den därefter.

För premiumanvändare kan vi se att roller är ["betalande-användare"] och både isPaidUser och isPremiumUser är true.

Uppdatera tjänsteleverantörens auktoriseringslogik#

I de tidigare stegen lade vi till anpassade fordringar baserat på affärsbehov till användarens åtkomsttoken. Därefter kan vi använda dessa fordringar för att snabbt utföra auktoriseringsverifiering.

Här erbjuder vi logiken för hur Logto verifierar JWT-åtkomsttoken på API-sidan. Den fullständiga kodimplementeringen finns i GitHub-repo:

Du kan hänvisa till Logto API:s logik för att verifiera åtkomsttoken och anpassa den enligt din egen affärslogik. Till exempel, för AI-assistentappens scenario som beskrivs här, kan du lägga till verifieringslogik för anpassade fordringar såsom roller, balans, numOfCallsToday, isPaidUser och isPremiumUser i funktionen verifyBearerTokenFromRequest.

Ovanstående exempel gäller scenariot där det påverkar slutanvändarens inloggning och erhållande av JWT-åtkomsttoken. Om ditt användningsfall är maskin-till-maskin (M2M) kan du också konfigurera anpassade JWT-fordringar för M2M-appar separat.

Att konfigurera anpassade JWT för användare kommer inte att påverka resultatet av M2M-appar som erhåller åtkomsttoken, och vice versa.

På grund av generellheten av M2M-anslutningar, tillhandahåller Logto för närvarande inte funktionen av getCustomJwtClaims-metoden för M2M-applikationer att acceptera intern data från Logto. I övrigt är konfigurationsmetoden för anpassade JWT för M2M-applikationer densamma som för användarapplikationer. Denna artikel kommer inte att fördjupa sig i det. Du kan använda Logtos anpassade JWT-funktion för att komma igång.

Varför använda anpassade JWT-fordringar?#

Vi har tillhandahållit AI Assistant-appen scenariet för John och hur man använder Logtos Custom JWT-funktion för att uppnå mer flexibel auktoriseringsverifiering. I denna process kan vi se fördelarna med Custom JWT-funktion:

1. Utan Custom JWT-funktion behöver användarna begära ett externt API (såsom det du gör i getCustomJwtClaims) varje gång de kontrollerar behörigheter. För tjänsteleverantören som tillhandahåller detta API, kan detta öka den extra bördan. Med Custom JWT-funktion kan denna information läggas direkt i JWT, vilket minskar de frekventa samtalen till det externa API:et.
2. För tjänsteleverantörer kan Custom JWT-funktion hjälpa dem att verifiera användarbehörigheter snabbare, särskilt när klienten ofta ringer till tjänsteleverantören, vilket förbättrar tjänstens prestanda.
3. Custom JWT-funktionen kan hjälpa dig att snabbt genomföra ytterligare auktoriseringsinformation som krävs av verksamheten, och informationen kan överföras mellan klienten och tjänsteleverantören på ett säkert sätt eftersom JWT är självförsörjande och kan krypteras så att det är svårt att förfalska.

Samtidigt, eftersom getCustomJwtClaims utförs varje gång en användare behöver Logto för att utfärda en åtkomsttoken, är det nödvändigt att undvika att utföra alltför komplex logik och externa API-förfrågningar med höga bandbreddskrav. Annars kan det ta för lång tid för slutanvändare att vänta på resultatet av getCustomJwtClaims under inloggningsprocessen. Om din getCustomJwtClaims returnerar ett tomt objekt, rekommenderar vi starkt att du tillfälligt tar bort denna konfigurationspost tills du faktiskt behöver använda den.

Slutsats#

I denna artikel har Logto utökat den grundläggande JWT-åtkomsttoken och utökat funktionen av extra JWT-fordringar för att låta användare lägga till ytterligare slutanvändarinformation i JWT-åtkomsttoken enligt deras affärsbehov, så att efter användarens inloggning kan användarbehörigheterna snabbt verifieras.

Vi tillhandahåller scenariot för Johns AI Assistant-app och demonstrerar hur man använder Logtos anpassade JWT-funktion för att uppnå mer flexibel auktoriseringsverifiering. Vi pekar också på några nyckelpunkter för att använda anpassade JWT:er. I kombination med faktiska affärsscenarier kan användare lägga olika användarrelaterad information i JWT-åtkomsttoken enligt deras affärsbehov, så att tjänsteleverantören snabbt kan verifiera användarbehörigheterna.