Lisää mukautettuja vaatimuksia JWT-käyttötunnuksille Logtossa tehostaaksesi valtuutusta

Aikaisemmissa artikkeleissa mainitsimme, että yhä useammat järjestelmät käyttävät JWT-muotoisia käyttötunnuksia käyttäjän todennukseen ja pääsynhallintaan. Yksi tärkeimmistä syistä tähän on, että JWT voi sisältää hyödyllistä tietoa, kuten käyttäjän roolit ja oikeudet. Tämä tieto voi auttaa siirtämään käyttäjätietoja palvelimen ja asiakkaan välillä, mikä mahdollistaa käyttäjän todennuksen ja pääsynhallinnan.

Yleensä JWT:n sisältämä tieto määräytyy todennuspalvelimen mukaan. OAuth 2.0 -protokollan mukaan JWT sisältää yleensä kenttiä kuten sub (kohde), aud (yleisö) ja exp (vanhenemisaika), joita kutsutaan usein vaatimuksiksi. Nämä vaatimukset voivat auttaa tarkistamaan käyttötunnuksen pätevyyden.

Kuitenkin on lukemattomia skenaarioita, joissa JWT:ta käytetään tietojen tarkistamiseen, ja tavalliset JWT-vaatimukset eivät usein vastaa käyttäjän tarpeita. Ihmiset usein ajattelevat, että koska JWT voi sisältää tietoa, voimmeko lisätä siihen tietoa helpottaaksemme valtuutusta?

Vastaus on KYLLÄ, voimme lisätä mukautettuja vaatimuksia JWT:hen, kuten nykyisen käyttäjän laajuuden ja tilausluokan. Tällä tavalla voimme siirtää käyttäjätietoja asiakkaan ja palvelimen välillä (tässä viittaa palvelimeen, joka tarjoaa erilaisia palveluita, myös nimeltään palveluntarjoaja), saavuttaaksemme käyttäjän todennuksen ja pääsynhallinnan.

Katso standardit JWT-vaatimukset kohdassa RFC7519. Logto, identiteettiratkaisu, joka tukee sekä todennusta että valtuutusta, on laajentanut resurssi- ja laajuusvaatimuksia tukeakseen standardia RBAC. Vaikka Logton RBAC-toteutus on standardi, se ei ole tarpeeksi yksinkertainen ja joustava katkaisemaan kaikki käyttötapaukset.

Tämän pohjalta Logto julkaisi uuden ominaisuuden mukautettujen JWT-vaatimusten muokkaamiseksi, mikä sallii käyttäjien muokata ylimääräisiä JWT-vaatimuksia, jotta käyttäjän todennus ja pääsynhallinta voidaan toteuttaa joustavammin.

Kuinka Logton mukautetut JWT-vaatimukset toimivat?#

Voit siirtyä Custom JWT -listauksen sivulle klikkaamalla "JWT claims" -painiketta sivupalkista.

Aloitetaan lisäämällä mukautettuja vaatimuksia loppukäyttäjille.

Vasemmalla puolella olevassa editorissa voit muokata omaa getCustomJwtClaims-funktiotasi. Tämä menetelmä sisältää kolme syöteparametria: token, data ja envVariables.

• token on raakakäyttötunnuksen hyötykuorma, joka on saatu nykyisen loppukäyttäjän todennustiedoista ja järjestelmäsi kokoonpanosta, sekä Logton käyttäjän pääsyyn liittyvistä tiedoista.
• data on kaikki Logtoon liittyvät tiedot käyttäjästä, mukaan lukien kaikki käyttäjän roolit, sosiaaliset kirjautumistunnukset, SSO-tunnukset, organisaatiojäsenyydet jne.
• envVariables ovat ympäristömuuttujat, jotka olet määrittänyt Logtossa nykyisen loppukäyttäjän käyttötunnuksen käyttötilanteeseen, kuten tarvittavat API-avaimet ulkoisiin API:hin jne.

Oikealla olevat kortit voidaan laajentaa näyttämään vastaavien parametrien esittely, ja voit myös asettaa ympäristömuuttujat nykyiseen tilanteeseen täällä.

Kun olet lukenut kaikista oikealla olevista korteista, voit siirtyä testitilaan, jossa voit muokata testitietoja ja käyttää muokattuja testitietoja tarkistaaksesi, täyttääkö kirjoittamasi koodin editorissa vasemmalla kirjoittamasi koodi odotuksesi.

Tässä on sekvenssikaavio, joka näyttää getCustomJwtClaims-funktion suoritusprosessin, kun loppukäyttäjä aloittaa todennuspyynnön Logtossa ja lopulta saa Logton palauttamana JWT-muotoisen käyttötunnuksen.

Jos Custom JWT -ominaisuutta ei ole otettu käyttöön, vaihe 3 kaaviossa ohitetaan ja vaihe 4 suoritetaan heti, kun vaihe 2 päättyy. Tässä vaiheessa Logto olettaa getCustomJwtClaims-palautusarvon olevan tyhjä objekti ja jatkaa sitten seuraavien vaiheiden läpikäyntiä.

Tehosta valtuutustasi mukautetuilla JWT-vaatimuksilla: käytännön esimerkki#

Edellisessä osassa esittelimme Logton mukautetun JWT:n toimintaperiaatteen. Tässä osassa näytämme, kuinka käyttää Logton mukautettuja JWT-vaatimuksia parantaaksesi valtuutuksen joustavuutta ja palveluntarjoajan suorituskykyä todellisen esimerkin kautta.

Skenaarion asetus#

Johnin tiimi kehitti tekoälyavustajasovelluksen, joka mahdollistaa käyttäjien keskustella tekoälyrobottien kanssa saadakseen erilaisia palveluita.

Tekoälyrobottipalvelut jaetaan ilmaisiin ja maksullisiin palveluihin. Ilmaisiin palveluihin kuuluvat erityiset lentotarjoukset, kun taas maksullisiin palveluihin kuuluvat osakeennusteet.

Tekoälyavustajasovellus käyttää Logtoa hallitsemaan kaikkia käyttäjiä, jotka on jaettu kolmeen tyyppiin: ilmaiskäyttäjät, etukäteen maksavat käyttäjät ja premium-käyttäjät. Ilmaiskäyttäjät voivat käyttää vain ilmaisia palveluja, etukäteen maksavat käyttäjät voivat käyttää kaikkia palveluita (käytön mukaan veloitettuna) ja premium-käyttäjät voivat käyttää kaikkia palveluita (mutta niillä on nopeusrajoituksia estääkseen väärinkäytön).

Lisäksi tekoälyavustajasovellus käyttää Stripe-palvelua käyttäjämaksujen hallintaan ja sillä on oma lokipalvelu käyttäjätoimintalokkien tallentamiseen.

Logto-kokoonpanot#

Luomme ensin API-resurssit tekoälyavustajasovelluksen palvelulle ja luomme kaksi laajuutta, recommend:flight ja predict:stock.

Sitten luomme kaksi roolia, free-user ja paid-user, ja annamme niille vastaavat laajuudet:

• Anna recommend:flight-laajuus free-user-roolille.
• Anna sekä recommend:flight että predict:stock-laajuudet paid-user-roolille.

Lopuksi luomme kolme käyttäjää, free-user, prepaid-user ja premium-user, ja annamme heille vastaavat roolit:

• Anna free-user-rooli käyttäjälle free-user.
• Anna paid-user-rooli käyttäjille prepaid-user ja premium-user.

Kuten alla olevassa kuvassa näkyy, voidaksemme toteuttaa edellä mainitun skenaarion vaatimaan valtuutustiedon, haluamme sisällyttää JWT:hen nykyisen sisäänkirjautuneen käyttäjän roles, balance ja numOfCallsToday -tiedot. Kun tarkistetaan käyttötunnus tekoälyavustajasovelluksessa, nämä tiedot voivat auttaa suorittamaan nopean käyttöoikeuksien tarkistuksen.

Kun envVariables on määritetty, toteutamme getCustomJwtClaims-funktion ja klikkaamme "Run test"-painiketta nähdäksesi nykyisten testitietojen perusteella saadun ylimääräisten JWT-vaatimusten tuloksen.

Koska emme ole määrittäneet testitietoja data.user.roles :lle, roles tulos näytetään tyhjänä listana.

Tarkista, toimiiko mukautettu JWT-ominaisuus#

Edellä esitellyn Logton konfiguraation mukaan saimme vastaavat tulokset testissä. Seuraavaksi käytämme Logton tarjoamaa esimerkkisovellusta tarkistaaksemme, onko mukautettu JWT tehokas. Etsi SDK, jonka kanssa olet tuttu, Logton SDK:t ja ota käyttöön esimerkkisovellus dokumentaation ja vastaavan GitHub-repon avulla.

Kuvaillun kokoonpanon perusteella, käyttäen esimerkiksi React SDK:ta, meidän on päivitettävä vastaava kokoonpano LogtoConfig:ssa:

Kun free_user-käyttäjä kirjautuu tekoälyavustajasovellusta simuloivaan esimerkkisovellukseen, voimme nähdä JWT-käyttötunnuksen hyötykuormassa lisäämämme tiedot roles, balance, numOfCallsToday, isPaidUser ja isPremiumUser.

Tiedot balance, numOfCallsToday, isPaidUser ja isPremiumUser ovat aiemman testin mukaisia, ja roles on ["free-user"]. Tämä johtuu siitä, että todellisessa loppukäyttäjän kirjautumisprosessissa saamme kaikki käyttäjän käytettävissä olevat tiedot ja käsittelemme ne vastaavasti.

Premium-käyttäjille voimme nähdä, että roles on ["paid-user"] ja sekä isPaidUser että isPremiumUser ovat true.

Päivitä palveluntarjoajan valtuutuslogiikka#

Aikaisemmissa vaiheissa lisäsimme liiketoiminnan tarpeisiin perustuvia mukautettuja vaatimuksia käyttäjän käyttötunnukseen. Seuraavaksi voimme käyttää näitä vaatimuksia suorittaaksemme nopean valtuutuksen tarkistuksen.

Tässä annamme Logton logiikan JWT-käyttötunnuksien tarkistamiseen API:n puolella. Kokonainen koodin toteutus löytyy GitHub-reposta:

Voit viitata Logton API:n logiikkaan käyttötunnusten tarkistamisessa ja mukauttaa sitä oman liiketoimintasi logiikan mukaan. Esimerkiksi täällä kuvatussa tekoälyavustajasovelluksen skenaariossa voit lisätä tarkistuslogiikan mukautettuja vaatimuksia, kuten roles, balance, numOfCallsToday, isPaidUser ja isPremiumUser verifyBearerTokenFromRequest-funktiossa.

Yllä oleva esimerkki koskee skenaariota, jossa se vaikuttaa loppukäyttäjän kirjautumiseen ja JWT-käyttötunnuksen saamiseen. Jos käyttötapauksesi on koneiden välinen (M2M), voit myös määrittää erikseen mukautetut JWT-vaatimukset M2M-sovelluksille.

Käyttäjille mukautettujen JWT-konfiguraatioiden asettaminen ei vaikuta M2M-sovellusten käyttötunnusten saamiseen, ja päinvastoin.

M2M-yhteyksien yleisyyden vuoksi Logto ei tällä hetkellä tarjoa getCustomJwtClaims-menetelmän toimintoa M2M-sovelluksille vastaanottaa sisäistä tietoa Logtosta. Muissa asioissa M2M-sovellusten mukautettujen JWT:n konfiguraatiomenetelmä on sama kuin käyttäjäsovelluksilla. Tämä artikkeli ei käy niitä läpi. Voit käyttää Logton mukautettua JWT-toimintoa päästäksesi alkuun.

Miksi käyttää mukautettuja JWT-vaatimuksia?#

Olemme esitelleet Johnin tekoälyavustajasovelluksen skenaarion ja kuinka käyttää Logton mukautettua JWT-ominaisuutta saavuttaaksemme joustavamman valtuutuksen tarkistuksen. Tässä prosessissa voimme nähdä mukautetun JWT-ominaisuuden edut:

1. Ilman mukautettua JWT ominaisuutta, käyttäjien täytyy pyytää ulkoista API:a (kuten mitä teet getCustomJwtClaims -metodissa) joka kerta tarkistaessaan oikeuksia. Tämän API:n tarjoavalle palveluntarjoajalle tämä voi lisätä ylimääräistä rasitusta. Mukautetun JWT-ominaisuuden avulla nämä tiedot voidaan laittaa suoraan JWT:hen, mikä vähentää ulkoisen API:n usein toistuvia kutsuja.
2. Palveluntarjoajille mukautettu JWT-ominaisuus voi auttaa heitä tarkistamaan käyttäjien käyttöoikeudet nopeammin, erityisesti silloin, kun asiakas kutsuu palveluntarjoajaa usein, parantaen palvelun suorituskykyä.
3. Mukautettu JWT-ominaisuus voi auttaa sinua nopeasti toteuttamaan liiketoiminnan edellyttämiä ylimääräisiä valtuutustietoja, ja tiedot voidaan siirtää asiakkaan ja palveluntarjoajan välillä turvallisella tavalla, koska JWT on itsenäinen ja voidaan salata, joten sen väärennystä on vaikea tehdä.

Samalla, koska getCustomJwtClaims suoritetaan joka kerta, kun käyttäjä tarvitsee Logton myöntävän käyttötunnuksen, on välttämätöntä välttää liian monimutkaisen logiikan ja suuria kaistavaatimuksia omaavien ulkoisten API pyyntöjen suorittamista. Muutoin loppukäyttäjien voi joutua odottamaan liian kauan getCustomJwtClaims-tulosta kirjautumisprosessin aikana. Jos getCustomJwtClaims palauttaa tyhjän objektin, suosittelemme vahvasti poistamaan tämän kokoonpanokohdan toistaiseksi, kunnes todella tarvitset sitä.

Johtopäätös#

Tässä artikkelissa Logto on laajentanut perus JWT-käyttötunnusta ja laajentanut ylimääräisten JWT-vaatimusten ominaisuutta, jotta käyttäjät voivat laittaa lisätietoja loppukäyttäjän tietoja JWT-käyttötunnukseen tarpeidensa mukaan, jotta käyttäjän kirjautuessa sisään, käyttäjän oikeudet voidaan nopeammin varmistaa.

Tarjoamme Johnin tekoälyavustajasovelluksen skenaarion ja näytämme kuinka käyttää Logton mukautettua JWT-ominaisuutta saavuttaaksemme joustavamman valtuutuksen tarkistuksen. Tuomme esiin myös joitain mukautettujen JWT:n käyttöä koskevia keskeisiä kohtia. Yhdistämällä liiketoiminnan tilanteita käyttäjät voivat liittää erilaisia käyttäjäkohtaisia tietoja JWT-käyttötunnukseen tarpeidensa mukaan, jolloin palveluntarjoaja voi nopeasti varmistaa käyttäjän käyttöoikeudet.