Opaakki token vs JWT

Logtossa, joka on OIDC-pohjainen kattava CIAM-alusta, valtuutustokeneilla on keskeinen rooli käyttäjän vuorovaikutuksen suojaamisessa ja resurssien käyttöoikeuksien hallinnassa. Erilaisten valtuutukseen käytettävien tokeneiden joukossa opakkitokenit ja JWT:t (JSON Web Tokeneet) ovat tärkeimmät.

Olemme saaneet useita kysymyksiä yhteisöltämme, kuten: Mikä on ero opakkitokenin ja JWT:n välillä? Miksi en voi dekoodata saamiani pääsytokeneita ja miksi tokenin pituus vaikuttaa lyhyeltä? Tämä blogikirjoitus pyrkii selkeyttämään näitä käsitteitä ja auttamaan sinua ymmärtämään erot opakkitokenien ja JWT:den välillä, niiden käyttötapaukset ja miksi saatat kohdata erilaisia käytöksiä työskennellessäsi niiden kanssa.

Mikä on opakkitoken?#

Opakkitoken on eräänlainen pääsytoken, joka, kuten nimi viittaa, on opakki tai ei-läpinäkyvä asiakkaalle tai millekään ulkopuoliselle taholle. Tämä tarkoittaa, että token itse ei sisällä luettavaa tietoa käyttäjästä tai annetusta valtuutuksesta.

Kun saat opakkitokenin, se näyttää usein satunnaiselta merkkijonolta, ja sen dekoodaamisyritys ei tuota mitään merkityksellistä tietoa.

Tässä on esimerkki opakkitokenista:

Koska tokenin todellinen sisältö on tunnettu vain sen myöntäneelle valtuutuspalvelimelle, opakkitokenin vahvistamiseksi asiakkaan on lähetettävä se takaisin palvelimelle, joka sitten vahvistaa sen aitouden ja määrittää siihen liittyvät oikeudet. Tämä lähestymistapa varmistaa, että arkaluontoinen tieto pysyy piilossa, tarjoten lisäturvakerroksen, mutta se vaatii myös lisäpalvelinviestintää tokenin vahvistamiseksi.

Plussat:

• turvallinen: Opakkitokenit eivät paljasta mitään arkaluontoista tietoa asiakkaalle. Tokenin sisältö on tunnettu vain valtuutuspalvelimelle.
• peruutettavissa: Koska token tallennetaan palvelimelle ja ainoa tapa vahvistaa se on introspektiopisteen kautta valtuutuspalvelimella, palvelin voi helposti peruuttaa tokenin tarvittaessa ja estää luvattoman pääsyn.
• pieni koko: Opakkitokenit ovat tyypillisesti lyhyempiä kuin JWT:t, mikä voi olla hyödyllistä suorituskyky- ja tallennusnäkökulmasta.

Miinukset:

• tilallinen: Opakkitokenit vaativat valtuutuspalvelimen ylläpitämään tilaa tokenin vahvistamiseksi, mikä voi aiheuttaa lisäkompleksisuutta ja -kuormitusta.
• suorituskyky: Tarve lisäpalvelinviestintään tokenin vahvistamiseksi voi vaikuttaa suorituskykyyn, erityisesti korkean liikenteen tilanteissa.

Mikä on JWT?#

Toisin kuin opakkitokenit, JWT (JSON Web Token) on itse sisältyvä, tilaton token, joka sisältää tietoa rakenteellisessa ja luettavassa muodossa.

JWT koostuu kolmesta osasta: header, payload ja signature, jokainen Base64URL-koodattuna.

Tässä on esimerkki JWT:stä:

• header sisältää tietoa tokenin tyypistä ja allekirjoituksen algoritmista. Esimerkiksi {"alg": "HS256", "typ": "JWT"}.
• payload osa sisältää väitteitä — tietoja käyttäjästä tai valtuutuksesta — kuten käyttäjätunnus, vanhenemisaika ja sovellukset. Koska nämä tiedot on koodattu mutta ei salattu, kuka tahansa, jolla on token, voi dekoodata sen nähdäksensä väitteet, vaikka he eivät voi muuttaa niitä ilman allekirjoituksen mitätöimistä. Määrittelyn ja valtuutuspalvelimen konfiguraation perusteella eri väitteitä voidaan sisällyttää kuormaan. Tämä antaa tokenille sen itse sisältyvän luonteen. Esimerkiksi {"sub": "1234567890", "name": "John Doe", "iat": 1516239022}.
• signature luodaan yhdistämällä header, payload ja salainen avain määritellyllä algoritmilla. Tätä allekirjoitusta käytetään tokenin eheyttä vahvistamiseen ja sen varmistamiseen, ettei sitä ole peukaloitu.

JWT:t ovat yleisesti käytössä, koska ne voidaan vahvistaa paikallisesti asiakkaan tai minkä tahansa palvelun toimesta ilman, että tarvitsee olla yhteydessä valtuutuspalvelimeen. Tämä tekee JWT:stä erityisen tehokkaita hajautetuissa järjestelmissä, joissa useat palvelut voivat erikseen vahvistaa tokenin aitouden.

Kuitenkin tämä kätevyys tulee myös vastuullisuusestä varmistaa, että tokenin väitteitä ei paljasteta liikaa, sillä ne ovat näkyvissä kaikille, joilla on pääsy tokeniin. Lisäksi JWT:t ovat tavallisesti lyhytaikaisia, ja vanhenemisaika sisältyy tokenin väitteisiin varmistaakseen, ettei token ole voimassa loputtomiin.

Plussat:

• tilaton: JWT:t ovat itse sisältyviä eikä niiden vahvistaminen vaadi palvelimen puolta tilaa.
• palveluiden välinen yhteensopivuus: JWT:t voidaan helposti jakaa ja vahvistaa eri palveluiden välillä, mikä tekee ne ihanteelliseksi hajautetuille järjestelmille.
• laajennettavissa: JWT:n kuorma voi sisältää mukautettuja väitteitä, jotka mahdollistavat joustavan valtuutuksen ja tietojen jakamisen.
• standardi: JWT:tokenit noudattavat hyvin määriteltyä standardia (RFC 7519), mikä tekee ne laajalti tuetuiksi ja yhteensopiviksi.

Miinukset:

• altistuminen: JWT:n väitteet ovat näkyvissä kenelle tahansa, joka pääsee tokeniin käsiksi, joten arkaluontoisia tietoja ei tule sisällyttää kuormaan.
• suuri koko: JWT:t voivat olla suurempia kuin opakkitokenit niiden lisätietojen vuoksi, mikä voi vaikuttaa suorituskykyyn ja tallennusnäkökulmiin. JWT-tokenien väitteiden tulisi olla minimaalisia tokenin koon vähentämiseksi.
• peruutuksen monimutkaisuus: Koska JWT:t ovat tilattomia, ne ovat tyypillisesti voimassa lyhyen aikaa, ja niiden etukäteisperuutukseen ei ole rakennettua mekanismia, eli vaarantunut token voi pysyä voimassa, kunnes se vanhenee.

Opaakin pääsytokenin vahvistaminen#

Opaakin pääsytoken vahvistetaan lähettämällä se takaisin valtuutuspalvelimelle varmistaakseen sen aitouden. Valtuutuspalvelimella on tieto myönnetyistä tokeneista ja se voi määrittää tokenin voimassaolon perustuen sen sisäiseen tallennukseen.

1. Asiakas pyytää pääsytokenia valtuutuspalvelimelta.
2. Valtuutuspalvelin myöntää opakkitokenin.
3. Asiakas lähettää resurssin käyttöpyynnön opakkitokenin kanssa headerissä.
4. Resurssin tarjoaja lähettää token introspektiopyynnön valtuutuspalvelimelle tokenin vahvistamiseksi.
5. Valtuutuspalvelin vastaa tokenin tiedoilla.

JWT pääsytokenin vahvistaminen (offline)#

JJWT pääsytoken voidaan vahvistaa offline-tilassa asiakkaan tai minkä tahansa palvelun toimesta, jolla on pääsy tokenin julkiseen avaimeen.

0. Resurssin tarjoaja hakee ennalta valtuutuspalvelimen julkisen avaimen OIDC hakemistopisteestä. Julkista avainta käytetään tokenin allekirjoituksen vahvistamiseen ja sen eheyden varmistamiseen.
1. Asiakas pyytää pääsytokenia valtuutuspalvelimelta.
2. Valtuutuspalvelin myöntää JWT tokenin.
3. Asiakas lähettää resurssin käyttöpyynnön JWT tokenin kanssa headerissä.
4. Resurssin tarjoaja dekoodaa ja vahvistaa JWT tokenin käyttämällä valtuutuspalvelimelta saatua julkista avainta.
5. Resurssin tarjoaja myöntää pääsyn perustuen tokenin voimassaoloon.

Käyttötapaukset OIDC:ssä#

Kulmassa OIDC (OpenID Connect), opakkitokeneilla ja JWT:llä on erilaiset tarkoitukset ja niitä käytetään eri tilanteissa.

Opakkitokenit#

1. Käyttäjäprofiilin noutaminen:

Oletuksena, kun asiakas pyytää pääsytokenia määrittelemättä resurssia ja sisällyttää openid laajuus, valtuutuspalvelin myöntää opakin pääsytokenin. Tämä token on ensisijaisesti käytetty käyttäjäprofiilitietojen noutamiseen OIDC /oidc/userinfo-pisteestä. Kun vastaanotat pyynnön opakin pääsytokenin kanssa, valtuutuspalvelin tarkistaa sisäisestä tallennuksestaan saadakseen liitetyn valtuutustiedon ja vahvistaa tokenin voimassaolon ennen kuin vastataan käyttäjäprofiilitiedoilla.

2. Uusimistokenin vaihto:

Uusimistokenit on suunniteltu vaihdettavaksi vain asiakkaan ja valtuutuspalvelimen välillä ilman, että niitä täytyy jakaa resurssin tarjoajien kanssa. Tämän vuoksi uusimistokenit ovat yleensä myönnettyinä opakkeina tokeneina. Kun nykyinen pääsytoken vanhenee, asiakas voi käyttää opakkia uusimistokenia saadakseen uuden pääsytokenin varmistaen jatkuvan pääsyn ilman, että käyttäjän täytyy uudelleenautentikoitua.

JWT:t#

1. ID token:

OIDC:ssä ID token on JWT, joka sisältää käyttäjätietoa ja jota käytetään käyttäjän autentikointiin. Tyypillisesti myönnetty yhdessä pääsytokenin kanssa, ID token mahdollistaa asiakkaan vahvistamaan käyttäjän identiteetin. Esimerkiksi:

Asiakas voi vahvistaa ID tokenin varmistaakseen käyttäjän identiteetin ja saadakseen käyttäjätietoa personointia tai valtuutustarkoituksiin. ID token on kertakäyttöinen ja sitä ei tule käyttää API-resurssin valtuutukseen.

2. API resurssin käyttö:

Kun asiakas pyytää pääsytokenia tietyn resurssiindikaattorin kanssa, valtuutuspalvelin myöntää JWT pääsytokenin, joka on tarkoitettu kyseisen resurssin käyttämiseen. JWT sisältää väitteitä, joita resurssin tarjoaja voi käyttää asiakkaan pääsyn valtuuttamiseen. Esimerkiksi:

Resurssin tarjoaja voi vahvistaa pyynnön tarkistamalla väitteet:

• iss: Varmistaa, että token on myönnetty luotetulta valtuutuspalvelimelta.
• sub: Tunnistaa käyttäjän, joka liittyy tokeniin.
• aud: Varmistaa, että token on tarkoitettu tietylle resurssille.
• scope: Vahvistaa käyttäjän oikeudet.

Yhteenveto#

Yhteenvetona, opakkitokeneilla ja JWT:llä on eri tarkoitukset OIDC-pohjaisissa järjestelmissä, opakkitokeneilla tarjotaan turvallinen ja tilallinen lähestymistapa valtuutukseen ja JWT:llä itse sisältyvä ja tilaton vaihtoehto. Ymmärtäminen näiden tokenien erojen ja käyttötapausten välillä on välttämätöntä turvallisten ja tehokkaiden autentikointi- ja valtuutusmekanismien suunnittelemiseksi sovelluksissasi.

Tutustu lisää pääsytoken-ominaisuuksiin Logtossa:

• Käytä RBAC:a suojataksesi API:si
• Organisaation pääsytokeni
• Mukautetut JWT väitteet