JWT vs. istuntoautentikointi

Yleisesti ottaen ensimmäinen askel sovelluksen käytössä on autentikointi, jossa loppukäyttäjä antaa tunnistetietonsa kirjautuakseen onnistuneesti sisään. Tämän vaiheen jälkeen identiteettijärjestelmä (ts. identiteettitoimittaja, autentikointipalvelin jne.) tietää, kuka käyttäjä on ja mihin resursseihin hänellä on pääsy.

Koska HTTP on luonteeltaan tilaton, jokainen pyyntö istunnossa on itsenäinen eikä muista tietoa aiemmista pyynnöistä. Käyttäjien uudelleenautentikoiminen jokaiselle toiminnolle on vaivalloista ja heikentää käyttäjäkokemusta.

Katsotaanpa istuntopohjainen autentikointi ja JWT (JSON Web Tokens) autentikointi, kaksi suosittua menetelmää autentikointitilan ylläpitämisessä. Kummallakin on omat etunsa ja vaihtokaupat, ja valinta niiden välillä riippuu sovelluksesi erityistarpeista. Jos olet päättämässä näiden kahden välillä, tämä opas on täällä auttamassa.

Mikä on istuntopohjainen autentikointi?#

Istuntopohjainen autentikointi perustuu palvelimeen, joka ylläpitää kirjaa käyttäjän autentikointitilasta. Luomalla ja hallitsemalla istuntoja palvelin mahdollistaa käyttäjien pysyä kirjautuneena ja jatkaa sovelluksen käyttöä ilman, että heidän tarvitsee syöttää tunnistetietoja jokaisella pyynnöllä.

Miten istuntopohjainen autentikointi toimii?#

Istunnon luonti

1. Käyttäjä autentikoi ja antaa joitain tunnistetietoja (esim. sähköposti ja salasana).
2. Jos tunnistetiedot ovat kelvollisia, palvelin luo pysyvän tietueen, joka edustaa kyseistä istuntoa. Istunto sisältää tietoja, kuten satunnaisen merkkijonon, käyttäjän tunnisteen, istunnon aloitusajan, istunnon vanhentumisajan jne.
3. SessionID tallennetaan tietokantaan ja palautetaan käyttäjän asiakkaalle evästeenä.

Istunnon validointi

1. Prosessi voidaan käynnistää manuaalisesti käyttäjän toimesta (esim. napauttamalla välilehteä, päivittämällä sivua) tai automaattisesti asiakkaan toimesta (esim. alkuperäisten sivujen latausten aikana tai API-kutsuilla SessionID:n kanssa).
2. Jokainen myöhempi pyyntö lähettää HTTP-pyynnön asiakkaalta, joka sisältää istuntoevästeen palvelimelle.
3. Palvelin validoi SessionID:n tarkistamalla palvelimelle tallennetut istuntotiedot.
4. Jos kelvollinen, palvelin käsittelee pyynnön ja valtuuttaa käyttäjän.

Miten peruuttaa istunto?#

Istunnot voidaan tehdä kelvottomiksi reaaliajassa, mikä on kätevää tilanteissa, joissa nopea pääsyn peruuttaminen on tarpeen.

• Käyttäjät kirjautuvat manuaalisesti ulos: Palvelin poistaa istuntotiedot, mikä käytännössä kirjaa käyttäjän ulos.
• Ylläpitäjät pakottavat käyttäjän kirjautumaan ulos: Ylläpitäjät tai järjestelmät voivat lopettaa tietyn istunnon poistamalla sen tietokannasta. Esimerkiksi tietoturvaloukkauksen aikana.
• Istuntojen vanhentuminen: Istunnot voivat vanhentua automaattisesti tietyn aktiivisuuden puutteella tai kiinteällä aikarajalla.

Istuntopohjaisen autentikoinnin edut#

• Yksinkertainen ja luotettava: Istuntotietue tarjoaa selkeän, keskitetyksen lähteen, mikä sallii korkean luottamusasteen ja tekee valtuutuspäätöksistä luotettavampia.
• Reaaliaikainen peruutus: Istuntotietueen poistamisella tai tekemällä se kelvottomaksi käyttäjän pääsy voidaan nopeasti peruuttaa.

Istuntopohjaisen autentikoinnin haitat#

• Viive hajautetussa järjestelmässä: Istuntotietojen ylläpito useilla palvelimilla vaatii aina istuntokaupan synkronointia. Tämä lisää viivettä, koska palvelimen on tarkistettava istuntokauppa jokaisen pyynnön yhteydessä.
• Korkea resurssien kulutus: Jokainen istunto vie palvelimen resursseja, mikä vaikuttaa suorituskykyyn käyttäjämäärän kasvaessa.
• Turvariski: Istuntokaappaus (varastettujen istuntoevästeiden avulla) voi sallia luvattoman pääsyn käyttäjätilille.
• Rajoitettu käyttö ohjelmointirajapintoihin: Istuntopohjainen autentikointi ei toimi hyvin mobiilisovelluksissa. Se tallentaa istuntotiedot palvelimelle, mikä voi lisätä kuormitusta ja monimutkaisuutta, kun käyttäjiä on paljon. Lisäksi se käyttää evästeitä, joita on vaikeampi käsitellä mobiililaitteissa.

Mikä on JWT-autentikointi?#

JSON Web Tokens (JWTs) ottaa erilaisen lähestymistavan sisällyttämällä kaikki asiaankuuluva käyttäjätieto suoraan tokeniin, käyttäen JSON-objektia. Toisin kuin istuntopohjaiset menetelmät, JWT:t ovat tilattomia, mikä tarkoittaa, että palvelin ei hallitse autentikointitietueita.

Miten JWT-autentikointi toimii?#

JWT koostuu kolmesta osasta: otsikko, kuorma ja allekirjoitus.

• Otsikko sisältää allekirjoitusalgoritmin (esim. HS256) ja tokenin tyyppi (JWT).
• Kuorma sisältää ydin väitteet, kuten käyttäjän identiteetti, käyttäjän rooli ja vanhentumisaika.
• Allekirjoitus käyttää avainta otsikon ja kuorman allekirjoittamiseen, mikä mahdollistaa tarkastamisen, onko allekirjoitusta peukaloitu.

JWT:n myöntäminen

1. Asiakas lähettää käyttäjätunnukset autentikointipalvelimelle (Yleismaailmallinen identiteettitoimittaja on erityisen hyödyllinen pääsynhallinnassa useissa toimialueissa.)
2. Onnistuneen autentikoinnin jälkeen palvelin luo JWT:n, joka sisältää otsikon, kuorman ja allekirjoituksen.
3. AuthServer lähettää myönnetyn tokenin asiakas. Asiakas tallentaa JWT:n (esim. evästeisiin, lokalSorageen tai sessionStorageen).

Istuntopohjaiset työprosessit noudattavat samanlaista prosessia. Kuitenkin autentikoinnin jälkeen käyttäjätieto tallennetaan palvelimelle istunnossa, kun taas JWT:t luottavat asiakastallenteisiin ja myöhempään käyttöön lähetettyihin tokeneihin.

Tokenin validointi

1. Seuraavia API-pyyntöjä varten asiakas lähettää JWT:n Authorization-otsakkeessä (Bearer <token>).
2. Palvelin tarkistaa JWT:n allekirjoituksen käyttäen salaisuutta tai julkista avainta ja tarkistaa sen väitteet (esim. erääntymisaika, issuer).
3. Jos token on kelvollinen, palvelin myöntää asiakkaalle pääsyn pyydettyyn resurssiin.

Istuntopohjainen autentikointi vaatii palvelimen kysyvän istuntokaupasta, mikä voi olla hidasta, erityisesti jos se luottaa ulkoisiin tai keskitetyihin tietokantoihin. Sen sijaan JWT-autentikointi on tilaton, ja kaikki tarvittava tieto tallennetaan asiakastokeneihin, ja se käyttää allekirjoitusta varmistaakseen turvallisuuden. Tämä eliminoi tarpeen istunnonhallintaan, tehden siitä nopeampaa ja skaalautuvampaa, erityisesti hajautetuissa järjestelmissä.

Miten peruuttaa JWT?#

Asiakaspuolella, uloskirjautuminen yleensä tarkoittaa paikallisen istunnon tyhjentämistä ja tokenin (ID, käyttö, päivitystoken) poistamista tallennuksesta. JWT-autentikoinnissa tämä kuitenkin vain kirjaa käyttäjän ulos paikallisesti, jättäen keskitetyn istunnon autentikointipalvelimelle ehjäksi. Näin ollen käyttäjät saattavat edelleen käyttää muita sovelluksia saman istunnon alla, kunnes token vanhentuu tai se peruutetaan manuaalisesti.

JWT:n (JSON Web Token) peruuttaminen on haastavampaa kuin istuntopohjainen autentikointi, koska JWT:t ovat tilattomia eikä niitä voida tehdä kelvottomiksi kerran myönnettyinä ilman erityisiä strategioita. Yleisiä menetelmiä ovat:

• Lyhyt vanhentumisaika: Aseta lyhyt exp-väite (esim. 15 minuuttia) JWT:lle. Kun se on vanhentunut, käyttäjän täytyy autentikoitua uudelleen. Tämä minimoi riskiä, jos token vaarantuu, koska hyökkääjä voi käyttää sitä vain rajoitetun ajan. Käyttäjäkokemuksen sujuvuuden säilyttämiseksi päivitystokenia voidaan käyttää minimoimaan uudelleenautentikoinnin haittaa.
• Tokenin estolista: Kriittisissä tapauksissa (esim. käyttäjän uloskirjautuminen, salasanan vaihdot), ylläpidetään peruutettujen tokenien estolista. Palvelin tarkistaa saapuvat tokenit tästä blocklististä ja hylkää mahdolliset osumat. Vaikka tehokas, tämä lähestymistapa vaatii peruutettujen tokenien seurannan, mikä on ristiriidassa JWT:iden tilattoman luonteen kanssa ja voi tulla tehottomaksi, jos lista kasvaa liian suureksi.
• Peruuttamispäätepiste: Ota käyttöön peruuttamispäätepiste autentikointipalvelimelle, missä tokeneita (esim. refresh tokenit) voidaan tehdä kelvottomiksi. Kun päivitystoken peruutetaan, kaikki siitä myönnetyt käyttötokenit eivät enää uusiudu. Tämä menetelmä toimii hyvin OAuth2 virtauksissa.

JWT-autentikoinnin edut#

• Nopea ja informatiivisempi: JWT:iden itsenäinen luonne tekee asiakaspuolen tarkistuksesta nopeamman ja tehokkaamman ilman palvelinvuorovaikutusta. Ne voivat sisältää myös mukautettuja väitteitä (esim. käyttäjän roolit tai muita asiaankuuluvia tietoja) tokenissa, mikä mahdollistaa palvelinten määritellä roolit ilman tietokantakyselyä.
• Parannettu turvallisuus: JWT:t käyttävät allekirjoitus- ja salausmenetelmiä, mikä tekee hyökkäyksistä vaikeampia.
• Toimialueiden välinen tuki: JWT:t ovat täydellisiä Single Sign-On (SSO) ja toimialueiden väliseen autentikointiin. Ne mahdollistavat käyttäjien autentikoinnin useissa toimialueissa tai palveluissa samalla tokenilla.
• Mobiiliystävällinen: JWT:t toimivat erinomaisesti mobiilisovelluksissa, jotka tarvitsevat tilatonta autentikointia. Tokenit voidaan tallentaa asiakaspuolelle ja lähettää jokaisen pyynnön yhteydessä, mikä parantaa tehokkuutta ja helppokäyttöisyyttä.

JWT-autentikoinnin haitat#

• JWT ei ole reaaliaikaisesti päivitettävä

  Kun JWT on allekirjoitettu, sitä ei voida peruuttaa tai päivittää, ja se katsotaan kelvolliseksi niin kauan kuin allekirjoitus on kelvollinen eikä ole vanhentunut.

  Jos käyttäjän käyttöoikeudet muuttuvat (yleensä heikennetään), käyttäjällä on edelleen poistettu pääsy resursseihin, kunnes JWT vanhentuu. Samoin, jos JWT sisältää roolipohjaista valtuutustietoa, uusi valtuutusalue ei tule voimaan ennen kuin vanha JWT vanhentuu. Toisin sanoen JWT:t eivät sovi reaaliaikaiseen peruutukseen ja käyttäjät voivat asettaa sopivan vanhentumisajan lieventääkseen tätä ongelmaa.

• Usean laitteen ja peruutuksen dilemman

  Kaikkia myönnettyjä JWT:eitä ei voida katuenkelin lailla ennen niiden vanhentumista toteuttamaan käyttäjän peruutusta kaikilta laitteilta. Vaikka on teoreettisesti mahdollista peruuttaa allekirjoitusavain tehdäkseen JWT:t kelvottomiksi, tämä tekisi myös kelvottomiksi kaikki JWT:t, jotka käyttävät kyseistä avainta, ja välimuistiavainten käsittelyprosessi tekisi tästä ratkaisutavasta epäkäytännöllisen yksinkertaisille käyttäjän peruutusoperaatioille.

Jotkut identiteettitoimittajat voivat tarjota valmiita ratkaisuja näihin JWT-ongelmiin. Lisätietoja varten, tarkista "Parhaat käytännöt JWT-autentikointikokemuksen parantamiseen.”

Mikä on ero JWT:in ja istunnon välillä?#

Istunnot ja JWT:t ovat kaksi suosittua lähestymistapaa autentikointi- ja valtuutusyhteyden säilyttämiseksi tilattomassa HTTP-maailmassa. Vaikka kummallekin lähestymistavalle on etuja ja haittoja, ne tarjoavat erilaisia etuja ja haittoja.

Istunnot tarjoavat vahvempia takeita yksilöityjen pyyntöjen valtuuttamiseen ja ovat yksinkertaisempia toteuttaa turvallisesti. Kuitenkin niiden riippuvuus palvelimen puolen tietokantatarkistuksista lisää viivekustannuksia, mikä voi heikentää käyttäjäkokemusta erittäin reagoivissa sovelluksissa.

JWT:t puolestaan ovat hyödyllisiä nopeampaan valtuutukseen ja ulkoisten sovellusten yhteensopivuuteen, mutta ne vaativat enemmän kehittäjiltä turvallisuushaasteiden ratkaisemista. Esimerkiksi, voimme käyttää verkkokoukkuja ilmoittaaksemme asiakkaille, kun käyttäjän pääsy on peruutettu, jotta asiakkaat voivat tyhjentää välimuistetun JWT:n ja pakottaa käyttäjän autentikoitumaan uudelleen.

Koska token-pohjainen autentikointi sopii paremmin skaalautumaan sen haitat ollessa hallittavissa, sitä omaksuu yhä useammat modernit sovellukset.

Istunto vs. JWT: Oikean menetelmän valitseminen#

Autentikointimenetelmäsi tulisi vastata sovelluksesi arkkitehtuuria ja erityistarpeita. Tässä on nopea opas auttamaan sinua päättämään:

Milloin käyttää istuntopohjaista autentikointia#

Istuntopohjainen autentikointi toimii parhaiten, kun tarvitset reaaliaikaista istuntonhallintaa, keskitettyä hallintaa tai skaalautuvuus ei ole suuri huolenaihe. Tässä se loistaa:

• Web-sovellukset, joissa on pysyvät istunnot

  Alustoille, kuten verkkokaupoille, istunnot ovat välttämättömiä seurattaessa käyttäjiä, ostoskoria ja mieltymyksiä heidän vierailunsa aikana.

• Sovellukset, jotka vaativat reaaliaikaista istuntonhallintaa

  Sovellukset, kuten pankki- tai rahoituspalvelut, hyötyvät palvelimen hallitsemista istuntotiedoista, varmistaen vankan pääsynhallinnan ja turvallisuuden.

• Yksipalvelin- tai pienemittakaavaiset järjestelmät

  Sisäiset työkalut tai pienemittakaavaiset sovellukset ilman suuria skaalautuvuustarpeita menestyvät yksinkertaisessa istuntonhallinnassa käytön ja luotettavuuden helppouden vuoksi.

Milloin käyttää JWT-autentikointia#

JWT-autentikointi sopii paremmin sovelluksiin, jotka priorisoivat skaalautuvuutta, tehokkuutta ja hajautettuja järjestelmiä. Se on erityisen hyödyllinen tilattomille vuorovaikutuksille asiakkaiden ja palvelimien välillä. Harkitse token-pohjaista autentikointia seuraaville:

• Single Sign-On (SSO)

  JWT:t ovat täydellisiä Single Sign-On, mahdollistaen käyttäjien autentikoitua kerran ja saumattomasti käyttää useita palveluita tai sovelluksia samalla tokenilla. Jaa yksityiskohtainen selitys turvallisista pilvipohjaisista sovelluksista käyttäen OAuth 2.0 ja OIDC, JWT-muodossa sekä käyttötokeneille että ID-tokeneille.

• Mobiilisovellukset

  Mobiilisovellukset yleensä suosivat JWT:eitä autentikoinnissa, koska tokeneita voidaan tallentaa turvallisesti laitteelle ja lähettää jokaisen API-pyynnön yhteydessä. Tutki nopeaa JWT-autentikoinnin integrointia Androidille / iOS:lle.

• Mikropalveluarkkitehtuurit

  Mikropalveluympäristöissä JWT:t mahdollistavat jokaisen palvelun itsenäisesti validoida tokenin ilman keskeistä istuntokauppaa, varmistaen skaalautuvuuden ja tehokkuuden.

• Toimialueiden välinen autentikointi

  JWT:t loistavat skenaarioissa, joissa on useita toimialueita tai alitoimialueita (esim. api.example.com, dashboard.example.com, ja docs.example.com). Toisin kuin evästeet, JWT:t mahdollistavat autentikoinnin toimialueiden välillä ilman lisäriippuvuuksia.

• API:t ja verkkopalvelut

  RESTful API:t ja verkkopalvelut käyttävät yleensä JWT:eitä autentikointiin, koska ne ovat kevyitä, kannettavia ja poistavat tarpeen palvelinpuolen istuntonhallinnasta. Opi lisää koneesta-koneeseen autentikointi skenaarioissa, joissa sovelluksesi tarvitsee kommunikoida suoraan resurssien kanssa.

Parhaat käytännöt JWT-autentikointikokemuksen parantamiseen#

JWT-autentikointi on erinomainen työkalu, mutta se voi aiheuttaa haasteita, jotka vaikuttavat käyttäjäkokemukseen. Logto tarjoaa helpon ja luotettavan ratkaisun näiden haasteiden voittamiseksi, mikä tekee siitä parhaimman valinnan turvalliselle ja tehokkaalle autentikoinnille.

Käyttäjän uloskirjautumisongelmien käsittely JWT:llä#

Yksi yleinen ongelma JWT-autentikoinnissa on varmistaa asianmukainen käyttäjän uloskirjautumiskokemus. Logto yksinkertaistaa tämän prosessin valmiilla SDK:llaan.

• Tyhjentämällä tokeneita ja paikallisia istuntoja asiakaspuolella ja ohjaamalla käyttäjät Logton istunnon lopetuspäätepisteelle voit helposti lopettaa istunnot sekä asiakassovelluksessa että palvelimella.
• Lisäksi Logto tukee back-channel uloskirjautumista, mahdollistaen AuthServerin ilmoittaa kaikille asiakassovelluksille, jotka jakavat saman istunnon, kun käyttäjä kirjautuu ulos.

Tämä varmistaa johdonmukaisen ja turvallisen istuntonhallinnan koko ekosysteemissäsi. Opi lisää uloskirjautumismekanismeista ja niiden toteuttamisesta.

Käyttäjän lupamuutoksiin reagointi#

JWT:llä reaaliaikaiset käyttäjän lupausten muutokset voivat olla hankalia hallita. Koska JWT:t ovat luonteeltaan tilattomia, kaikki päivitetyt luvat tai roolit eivät voi tulla voimaan ennen kuin token vanhenee. Logto tarjoaa ratkaisuja tähän:

• Käyttäjän lupien vähentämiseksi: Käytä lyhyitä käyttäjätokenien vanhentumisaikoja tai dynaamisesti varmista luvat API-kutsun kautta.
• Käyttäjän uusien lupien lisäämiseksi: Päivitä AuthServer sisällyttämään uusi lupien ala ja uudelleenpyydä käyttäjiltä suostumus näiden muutosten soveltamiseksi.

Nämä ratkaisut auttavat pitämään luvat ajan tasalla ja varmistavat turvallisemman ja reagoivamman järjestelmän. Opi lisää reaaliaikaisten käyttäjän lupausten muutosten hallitsemisesta.

Logto, joka on skaalautuva identiteetin pääsynhallintainfrastruktuuri, tarjoaa täydellisen identiteettiratkaisun, jossa on sekä pilvipalvelu että avoin lähdekoodi saatavilla.