Opaakki token vs JWT
Ymmärrä erot opakkitokeneiden ja JWT:den välillä, niiden käyttötapaukset ja miten ne vahvistetaan OIDC-pohjaisissa järjestelmissä.
Ymmärrä erot opakkitokeneiden ja JWT:den välillä, niiden käyttötapaukset ja miten ne vahvistetaan OIDC-pohjaisissa järjestelmissä.
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.
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:
Miinukset:
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ä:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cheader 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:
Miinukset:
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.
JJWT pääsytoken voidaan vahvistaa offline-tilassa asiakkaan tai minkä tahansa palvelun toimesta, jolla on pääsy tokenin julkiseen avaimeen.
Kulmassa OIDC (OpenID Connect), opakkitokeneilla ja JWT:llä on erilaiset tarkoitukset ja niitä käytetään eri tilanteissa.
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.
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.
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.
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.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: