Miksi JWT useimmissa OAuth 2.0 -palveluissa

OAuth 2.0 on laajasti käytössä nykyään. Yhden käyttöoikeuspalvelujen ydinkehyksenä OAuth 2.0:n päävastuualue on myöntää käyttäjille pääsytunnuksia. Olemme huomanneet, että monet markkinoilla olevat OAuth-palveluntarjoajat myöntävät pääsytunnuksia JWT-muodossa.

Tässä artikkelissa esittelemme, mitä JWT on ja miksi sitä käytetään laajalti OAuth 2.0:n myöntämien pääsytunnusten muodossa.

Johdanto JWT:hen#

JWT tarkoittaa JSON Web Tokenia, ja se on määritelty RFC 7519 seuraavasti:

JSON Web Token (JWT) on kompakti, URL-turvallinen keino esittää vaatimuksia, joita siirretään kahden osapuolen välillä.

Tämä määritelmä tekee selväksi, että JWT on tunnus, jota käytetään siirtämään vaatimuksia eri osapuolten välillä.

Koska JWT:t siirretään useiden osapuolten välillä, ne allekirjoitetaan tietojen eheyden ja aitouden varmistamiseksi.

Allekirjoitetulla JWT:llä on seuraava muoto:

Se koostuu kolmesta osasta, jotka on erotettu .: otsikko, sisältö ja allekirjoitus.

Tässä esimerkki tosielämän JWT:stä:

Voit kokeilla sen jäsentämistä osoitteessa https://jwt.io:

Kuvassa näytetään, että JWT:n header-osio sisältää tietoa käytetystä allekirjoitusalgoritmista ja tunnuksen tyypistä. Payload-osio sisältää JWT:n kantamat vaatimukset, ja signature-osiota käytetään varmistamaan JWT:n eheys.

Nyt kun ymmärrämme, mitä JWT on ja mitä sen eri osat tarkoittavat, jatketaan selittämällä, miksi monet OAuth-käyttöoikeuspalvelut valitsevat JWT:n pääsytunnuksekseen.

JWT:n käytön edut#

Tärkeimmät erot JWT:n ja perinteisten satunnaisesti luotujen merkkijonopohjaisten tunnusten välillä ovat se, että JWT:t voivat kantaa tietoa ja voidaan varmistaa dekoodauksen kautta. Nämä erot tuovat mukanaan kaksi merkittävää etua:

• Resurssitehokkuus: JWT:t voivat kantaa tietoa käyttäjästä tai istunnosta, mikä poistaa tarpeen usein tietokantahauille. Tämä tehokkuus voi vähentää palvelujen resurssien kulutusta.
• Parannettu saatavuus ja skaalautuvuus: JWT:t vähentävät riippuvuutta palvelinpuolen tilan hallinnasta. Tämä mahdollistaa palvelujen olevan enemmän tilattomia, mikä parantaa niiden saatavuutta ja skaalautuvuutta.

Kun käytetään perinteisiä satunnaisia merkkijonopohjaisia tunnuksia, tyypillinen prosessi validoinnille ja todentamiselle on seuraava:

Kuten kaaviossa on esitetty, kun järjestelmässä on lukuisia käyttäjiä ja monia eri resurssipalvelimia, se voi johtaa lukuisiin tunnuksen validointipyyntöihin todentamispalvelimelle.

Ajan mittaan järjestelmän kasvaessa todentamispalvelin voi helposti muodostua pullonkaulaksi, joka aiheuttaa haasteen koko palvelun saatavuudelle.

Kuitenkin, kun JWT:t otetaan käyttöön, validointiprosessi muuttuu seuraavasti:

Kiitos JWT:n piirteen, joka mahdollistaa validoinnin dekoodauksen kautta, resurssipalvelin voi tarkistaa JWT:n eheyden ja poimia käyttäjätiedot siitä ilman tarvetta olla vuorovaikutuksessa todentamispalvelimen kanssa (yksityiskohtaisesti JWT:n dekoodaus ja validointi löytyy Logto dokumentaatiosta).

JWT:n rajoitukset#

Vaikka JWT:llä on merkittäviä etuja nykyaikaisissa ohjelmistoarkkitehtuureissa, niissä on myös rajoituksia huomioitavaksi.

Helposti urkittava sisältö#

Kuten aiemmin mainittiin, JWT koostuu kolmesta osasta: header,payload ja signature. Miten nämä komponentit luodaan? Otetaanpa JWT edellisestä esimerkistä ja esitetään JWT:n luomisprosessi:

Kuten yllä olevassa koodissa näkyy, JWT:n header ja payload koodataan yksinkertaisesti base64-merkkijonoiksi.

Tämä tarkoittaa, että niin kauan kuin jollakin on pääsy tunnukseen, hän voi helposti dekoodata JWT:n payloadin base64- merkkijonon ja päästä käsiksi sen tietoihin. Toisaalta on myös suhteellisen helppoa väärentää payloadia ja korvata alkuperäisen JWT:n payload väärennetyllä.

Vaikka on totta, että JWT:n payload voidaan suhteellisen helposti väärentää, on tärkeää huomata, että JWT:n signature-osaa ei voi korvata väärennetyllä sisällöllä, sillä se vaatii salaista allekirjoitusavainta. Siksi ilman oikeaa allekirjoitusta JWT ei voi läpäistä validointia.

Kun käytetään JWT:ta, on tärkeää pitää mielessä seuraavat seikat:

1. Käytä aina SSL:ää: On varmistettava, että JWT-tieto ei vuoda siirron aikana, on käytettävä SSL (Secure Sockets Layer) tai sen seuraajaa, TLS (Transport Layer Security), suojaamaan dataa siirrossa.
2. Vältä arkaluonteisten tietojen tallentamista: Ei ole suositeltavaa tallentaa arkaluonteista tietoa JWT:n payloadiin. Kuten aiemmin mainittiin, payload voidaan helposti dekoodata, ja sen tulisi sisältää ensisijaisesti ei-arkaluonteisia, merkityksellisiä vaatimuksia.
3. Varmista JWT:t: Ennen kuin luotat JWT:hen sisältyvään tietoon, varmista, että se on läpäissyt pätevän ja turvallisen validointiprosessin, mukaan lukien allekirjoituksen tarkistus ja tarkistamalla tokenin vanheneminen. Tämä auttaa estämään manipuloitujen tai luvattomien tokenien käyttöä.

Vaikeasti peruutettavissa#

Yleensä pääsytunnuksilla on yleensä vanhenemisaika. Jos pääsytunnus esitetään satunnaisina merkkijonoina ilman mitään tietoa, voimme tarkistaa, onko tunnus peruutettu jokaisen validoinnin aikana todentamispalvelimella.

JWT:n osalta, koska JWT:t sisältävät vanhenemistietoa itsessään, ja JWT-validointi ei ole riippuvainen todentamispalvelimesta, kerran kun todentamispalvelin myöntää pääsytunnuksen JWT-muodossa, tunnuksen tilaa ei voi muuttaa sen käytön aikana.

Kun JWT-tunnus luonnollisesti vanhenee, voimme hankkia uuden JWT:n valtuutuspalvelimelta käyttämällä päivitystunnusta (voit viitata Logton blogiin saadaksesi tietoa päivitystunnuksista).

Kuitenkin tietyissä tilanteissa, kuten silloin, kun käyttäjä peruuttaa valtuutuksensa tai vaihtaa salasanansa, ja sinun tarvitsee peruuttaa jo myönnetty mutta vielä vanhentumaton tunnus, ei ole suoraa ratkaisua saatavilla.

On kaksi yleistä lähestymistapaa lieventämään keskenkauden tokenien peruutuksen vaikutuksia:

1. Aseta lyhyempi vanhenemisaika pääsytunnukselle ja luota tokenin päivitysmekanismiin päivittääksesi tokenin tila nopeasti.

Koska pääsytunnuksella on lyhyempi vanhenemisaika, kun käyttäjä huomaa pääsytunnuksen vanhentuneen, hän voi pyytää uutta pääsytunnusta päivitystunnuksella valtuutuspalvelusta. Näin tokenin tila käyttäjän puolella voi synkronoitua backendiin mahdollisimman pian. Tämä lähestymistapa tuo kuitenkin mukanaan lisäkuormaa, mitä käyttäjien on otettava huomioon.

2. Ylläpidä peruutuslista pääsytunnuksille ja tarkista jokaisen validoinnin aikana, onko tunnus listassa.

Tällä menetelmällä on tiettyjä rajoituksia. Yksi JWT:n eduista on se, että se ei vaadi palvelimen säilyttävän tilatietoa, ja JWT:t ovat yleensä tilattomia. Kuitenkin, peruutuslistan ylläpito vaatii tehokasta tallennusta ja ylläpitoa, jättäen luottaen lisätallennusmekanismeihin. Tämä käytännössä uhraa JWT:n edut ja voi johtaa suorituskykyongelmiin. Siksi tokenin peruutusmekanismi on toteutettava kehittäjien toimesta tavalla, joka sopii heidän erityistapaukseensa.

Yhteenveto#

Tässä artikkelissa annoimme lyhyen johdannon JWT:hen, highlighting sen edut ja rajoitukset. Nyt sinun pitäisi olla syvempi ymmärrys JWT:sta ja siitä, millaisissa tilanteissa sitä käytetään yleisesti. Vaikka JWT:llä on omat haasteensa, sen edut, kun sitä käytetään token -muotona OAuth 2.0 -palveluissa, ovat huomattavasti sen haittoja suurempia.

Logto, nopeasti kasvava identiteettitodentamispalvelu, käyttää myös JWT:tä pääsytunnustensa muotona. Se noudattaa tiukasti erilaisia valtuutus- ja todennusprotokollia, mikä tekee siitä poikkeuksellisen helpon integroida identiteettitodentamispalvelut tuotteisiisi. Logto on virallisesti lanseerannut SaaS-palvelunsa, ja voit kokeilla sitä ilmaiseksi tänään.