JWT vs Istuntojen todentaminen

Yleisesti ottaen sovelluksen käytön ensimmäinen vaihe on todennus, jossa loppukäyttäjä antaa henkilöllisyyden todisteensa kirjautuakseen onnistuneesti sisään. Tämän vaiheen jälkeen identiteettijärjestelmä (esim. identity provider, todennuspalvelin jne.) tietää, kuka käyttäjä on ja mihin resursseihin hänellä on pääsy.

Koska HTTP on luontaisesti tilaton, jokainen pyyntö istunnossa on itsenäinen, eikä se muista aiempien pyyntöjen tietoja. Käyttäjien uudelleen todennus jokaisen toiminnon yhteydessä on hankalaa ja heikentää käyttäjäkokemusta.

Astutaan sisään istuntopohjainen todennus ja JWT (JSON Web Tokens) todennus, jotka ovat kaksi suosittua menetelmää todennustilan ylläpitämiseksi. Jokaisella on ainutlaatuisia etuja ja kompromisseja, ja valinta riippuu sovelluksesi erityistarpeista. Jos olet päättämässä näiden kahden välillä, tämä opas on täällä auttamassa.

Mitä on istuntopohjainen todennus?#

Istuntopohjainen todennus luottaa palvelimeen pitämään kirjaa käyttäjän todennustilasta. Luomalla ja hallitsemalla istuntoja palvelin mahdollistaa käyttäjien pysymisen kirjautuneena ja toimimisen sovelluksen kanssa uudelleen syöttämättä todennistietoja joka pyyntöön.

Kuinka istuntopohjainen todennus toimii?#

Istunnon luominen

1. Käyttäjä todentaa ja antaa joitain tunnistetietoja (esim. sähköposti ja salasana).
2. Jos tunnistetiedot ovat voimassa, palvelin luo pysyvän tietueen, joka edustaa kyseistä istuntoa. Istunto sisältää tietoja, kuten satunnainen merkkijono, käyttäjän tunniste, istunnon alkamisaika, istunnon päättymisaika jne.
3. SessionID tallennetaan tietokantaan ja palautetaan käyttäjän asiakkaalle evästeenä.

Istunnon validointi

1. Prosessin käyttäjä voi käynnistää manuaalisesti (esim. napsauttamalla välilehteä, päivittämällä sivua) tai automaattisesti asiakas (esim. aloitussivun latauksen aikana tai API-kutsujen SessionID:n avulla).
2. Jokainen seuraavat kutsut lähettää HTTP-pyynnön asiakkaalta sisältäen istuntoevästeen palvelimelle.
3. Palvelin tarkistaa SessionID:n konsultoimalla palvelimelle tallennettua istuntodata.
4. Jos se on voimassa, palvelin käsittelee pyynnön ja valtuuttaa käyttäjän.

Kuinka mitätöidä istunto?#

Istuntoja voidaan mitätöidä reaaliajassa, mikä on kätevää tilanteissa, joissa nopea pääsyn mitätöinti on tarpeen.

• Käyttäjä kirjautuu ulos manuaalisesti: Palvelin poistaa istuntotietueen, käytännössä kirjaten käyttäjän ulos.
• Ylläpitäjät pakottavat käyttäjän uloskirjautumisen: Ylläpitäjät tai järjestelmät voivat lopettaa tietyn istunnon poistamalla sen tietokannasta. Esimerkiksi tietoturvaloukkauksen yhteydessä.
• Istuntojen vanhentuminen: Istunnot voivat automaattisesti vanhentua tietyn passiivisuusajan jälkeen tai kiinteän aikarajan umpeuduttua.

Istuntopohjaisen todennuksen edut#

• Yksinkertainen ja luotettava: Istuntotietue tarjoaa selkeän, keskitetyn lähteen, mikä mahdollistaa suuren luottamustason ja tekee valtuutuspäätöksistä luotettavampia.
• Reaaliaikainen mitätöinti: Poistamalla tai mitätöimällä istuntotietueen käyttäjän pääsy voidaan nopeasti mitätöidä.

Istuntopohjaisen todennuksen haitat#

• Viiveet hajautetussa järjestelmässä: Istuntotietojen ylläpitäminen useilla palvelimilla vaatii aina istuntotallennuksen synkronointia. Tämä lisää ylimääräistä viivettä, koska palvelimen on tarkistettava istuntotallennus aina, kun pyyntö tehdään.
• Suuri resurssikulutus: Jokainen istunto vie palvelinresursseja, mikä vaikuttaa suorituskykyyn, kun käyttäjämäärä kasvaa.
• Tietoturvariski: Istunnon kaappaus (varastettujen istuntoevästeiden avulla) voi mahdollistaa luvattoman pääsyn käyttäjätiliin.
• Rajoitettu käyttö rajapinnoissa: Istuntopohjainen todennus ei sovi hyvin mobiilisovelluksiin. Se tallentaa istuntotiedot palvelimelle, mikä voi lisätä kuormitusta ja monimutkaisuutta useiden käyttäjien kanssa. Lisäksi se käyttää evästeitä, joita on vaikeampaa käsitellä mobiililaitteissa.

Mitä on JWT-todennus?#

JSON Web Tokens (JWTs) ottavat erilaisen lähestymistavan upottamalla kaikki käyttäjän relevantit tiedot suoraan tunnukseen käyttäen JSON-objektia. Toisin kuin istuntopohjaiset menetelmät, JWT:t ovat tilattomia, mikä tarkoittaa, että palvelin ei hallitse todennustietueita.

Kuinka JWT-todennus toimii?#

JWT koostuu kolmesta osasta: otsikko, kuorma ja allekirjoitus.

• Otsikko sisältää allekirjoitusalgoritmin (esim. HS256) ja tunnuksen tyypin (JWT).
• Kuorma sisältää keskeiset vaatimukset, kuten käyttäjän henkilöllisyyden, käyttäjän roolin ja päättymisajan.
• Allekirjoitus käyttää avainta otsikon ja kuorman allekirjoittamiseen, mahdollistamalla varmennuksen siitä, onko allekirjoitukseen kajottu.

JWT:n myöntäminen

1. Asiakas lähettää käyttäjän tunnistetiedot todennuspalvelimelle (Yleismaailmallinen identiteetin tarjoaja on erityisen hyödyllinen hallita pääsyä useiden toimialueiden välillä.)
2. Onnistuneen todennuksen jälkeen palvelin luo JWT:n, joka sisältää otsikon, kuorman ja allekirjoituksen.
3. AuthServer lähettää myönnetyn tunnuksen Asiakkaalle. Asiakas tallentaa JWT:n (esim. evästeisiin, localStorageen tai sessionStorageen).

Istuntopohjaiset työnkulut seuraavat samankaltaista prosessia. Kuitenkin todennuksen jälkeen käyttäjätiedot tallennetaan palvelimelle istunnon sisään, kun taas JWT:t tukeutuvat tunnuksiin, jotka lähetetään asiakkaalle tallennusta ja myöhempää käyttöä varten.

Tunnuksen validointi

1. Seuraavia API-pyyntöjä varten asiakas lähettää JWT:n Authorization-otsikossa (Bearer <token>).
2. Palvelin vahvistaa JWT:n allekirjoituksen käyttämällä salaista tai julkista avainta ja tarkistaa sen vaatimukset (esim. päättymis-, toimittaja).
3. Jos tunnus on voimassa, palvelin antaa käyttäjälle pääsyn pyydettyihin resursseihin.

Istuntopohjainen todennus vaatii palvelimen kysyvän istuntotallennusta, mikä voi olla hidasta, erityisesti jos se riippuu ulkoisista tai keskitetystä tietokannasta. Toisin kuin JWT-todennus on tilaton, kaikki tarvittavat tiedot ovat tallennettuna asiakastunnukseen, ja sen käyttöön otetaan allekirjoitus varmuuden takaamiseksi. Tämä eliminoi istuntojen hallinnan tarpeen ja tekee siitä nopeamman ja skaalauskelpoisemman, erityisesti hajautetuissa järjestelmissä.

Kuinka mitätöidä JWT?#

Asiakaspäässä uloskirjautuminen tarkoittaa yleensä paikallisen tilan puhdistamista ja tunnusten (ID, access, refresh token) poistamista tallennuksesta. Kuitenkin JWT-todennuksen tapauksessa tämä kirjaa käyttäjän ulos vain paikallisesti, jättäen keskitetyn istunnon todennuspalvelimelle koskemattomaksi. Tämän seurauksena käyttäjillä voi silti olla pääsy muihin sovelluksiin saman istunnon aikana, kunnes tunnus vanhenee tai se poistetaan manuaalisesti.

JWT:n (JSON Web Token) mitätöinti on haastavampaa kuin istuntopohjaisen todennuksen, koska JWT:t ovat tilattomia ja niitä ei voida mitätöidä niiden myöntämisen jälkeen, ellei tiettyjä strategioita oteta käyttöön. Tavallisia menetelmiä ovat:

• Lyhyet vanhenemisajat: Aseta lyhyt exp-väite (esim. 15 minuuttia) JWT:lle. Kun se on vanhentunut, käyttäjän on todennettava uudelleen. Tämä minimoi riskin, jos tunnus vaarantuu, koska hyökkääjä voi käyttää sitä vain rajoitetun ajan. Säilyttääkseen saumattoman käyttäjäkokemuksen, uudelleentunnus voidaan käyttää vähentämään uudelleentodentamisen vaivaa.
• Tunnuksen musta lista: Kriittisissä tapauksissa (esim. käyttäjän uloskirjautuminen, salasanan muutokset), ylläpidä musta lista peruutetuista tunnuksista. Palvelin tarkistaa saapuvat tunnukset tätä estolistaa vastaan ja hylkää kaikki osumat. Vaikka tehokas, tämä lähestymistapa vaatii peruutettujen tunnusten seuraamista, mikä on vastoin JWT:iden tilatonta luonnetta ja voi tulla tehottomaksi, jos lista kasvaa liian suureksi.
• Mitätöimisrajapinta: Esittele mitätöimisrajapinta todennuspalvelimelle, jossa tunnukset (esim. uudelleentunnukset) voidaan mitätöidä. Kun uudelleentunnus mitätöidään, kaikki siitä myönnetyt pääsytunnukset eivät enää uusita. Tämä menetelmä toimii hyvin OAuth2 -virtausessa.

JWT-todennuksen edut#

• Nopea ja informatiivisempi: JWT:ien itsehallittu luonne tekee asiakaspään varmentamisesta nopeampaa ja tehokkaampaa ilman tarvetta palvelimen vuorovaikutukselle. Ne voivat sisältää myös mukautettuja väitteitä (esim. käyttäjärooleja tai muita liittyviä tietoja) tunnuksen sisällä, mahdollistaen palvelimille päättää roolit ilman tietokannan kyselyä.
• Parannettu turvallisuus: JWT:t käyttävät allekirjoitus- ja salausmenetelmiä, mikä tekee hyökkäyksistä vaikeampia.
• Monialuetuki: JWT:t ovat täydellisiä kerta kirjautumiseen (SSO) ja monialueen todennukseen. Ne mahdollistavat käyttäjän todentamisen useiden aluetai palveluiden välillä samalla tunnuksella.
• Mobiiliystävällinen: JWT:t toimivat hyvin mobiilisovelluksissa, jotka tarvitsevat tilattoman todennuksen. Tunnukset voidaan tallentaa asiakaspuolelle ja lähettää jokaisessa pyynnössä, parantaen tehokkuutta ja käyttömukavuutta.

JWT-todennuksen haitat#

• JWT:tä ei päivitetä reaaliajassa

  Kun JWT on allekirjoitettu, sitä ei voida mitätöidä tai päivittää, ja se katsotaan voimassaolevaksi niin kauan kuin allekirjoitus pysyy validina ja ei ole vanhentunut.

  Jos käyttäjän pääsyoikeudet muuttuvat (yleensä alennettu), käyttäjä säilyy pääsyt resursseihin, kunnes JWT vanhenee. Vastaavasti, jos JWT sisältää roolipohjaisia valtuutustietoja, uusi valtuutuslaajuus ei tule voimaan ennen vanhan JWT:n vanhenemista. Toisin sanoen, JWT:t eivät sovellu reaaliaikaiseen peruutukseen, ja käyttäjä voi asettaa sopivan vanhenemisajan lieventääkseen tätä ongelmaa.

• Usean laitteen ja peruutuksen dilemma

  Ei ole mahdollista validoida kaikkia myönnettyjä JWT:tä ennen niiden vanhenemista käyttäjän peruutuksen toteuttamiseksi kaikille laitteille. Vaikka on teoriassa mahdollista mitätöidä allekirjoitusavain tehdäksesi JWT:n keelemättä, tämä mitätöisi myös kaikki JWT:t, jotka käyttävät kyseistä avainta, ja välimuistiavaimen käsittelyn prosessi tekee tästä lähestymistavasta epäkäytännöllisen yksinkertaisille käyttäjän peruutustoimille.

Jotkut identiteetin tarjoajat voivat tarjota ennaltarakennettuja ratkaisuja näihin JWT-ongelmiin. Katso lisätietoja "Hyvät käytännöt JWT-todennuksen parantamiseen.”

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

Istunnot ja JWT:t ovat kaksi suositua menetelmää todennus- ja valtuutuskontekstin säilyttämiseksi tilattomassa HTTP-maailmassa. Vaikka molemmilla lähestymistavoilla on hyvät ja huonot puolensa, ne tarjoavat erilaisia etuja ja haittoja.

Istunnot tarjoavat vahvempia takuita yksittäisen pyynnön valtuutukseen ja ovat helpompia toteuttaa turvallisesti. Kuitenkin niiden riippuvuus palvelinpuolen tietokantavalidoinnista aiheuttaa viiveen ylikuormituksen, mikä voi heikentää käyttäjäkokemusta erittäin herkkätoimisille sovelluksille.

JWT:t puolestaan ovat suotuisia nopeampaan valtuutukseen ja yhteensopivuuteen ulkoisten sovellusten kanssa, mutta vaativat enemmän kehittäjien ponnisteluja tietoturvamonimutkaisuuksien ratkaisemiseksi. Esimerkiksi, voimme käyttää verkkokoukkua ilmoittamaan asiakkaille, kun käyttäjän pääsy on mitätöity, jotta asiakkaat voivat tyhjentää välimuistiin tallennetun JWT:n ja pakottaa käyttäjän uudelleen todentautumaan.

Koska tunnuspohjainen todennus soveltuu paremmin laajennettavaksi, vaikka siinä on edelleen hallittavia haittoja, sitä otetaan käyttöön yhä useammissa moderneissa sovelluksissa.

Istunto vs. JWT: Valitse oikea menetelmä#

Todennusmenetelmän pitäisi vastata sovelluksesi arkkitehtuuria ja erityistarpeita. Tässä nopea opas päätöksen tueksi:

Milloin käyttää istuntopohjaista todennusta#

Istuntopohjainen todennus toimii parhaiten, kun tarvitset reaaliaikaista istunnon hallintaa, tarvitset keskitettyä hallintaa tai skaalautuvuus ei ole suuri huolenaihe. Tässä tilanteet, joissa se loistaa:

• Verkkosovellukset, joissa on pysyviä istuntoja

  Alustoille, kuten verkkokauppasivustoille, istunnot ovat välttämättömiä käyttäjien, ostoskorien ja mieltymyksien seuraamiseksi heidän vierailunsa aikana.

• Sovellukset, jotka vaativat reaaliaikaista istunnon hallintaa

  Sovellukset, kuten pankki- tai rahoituspalvelut, hyötyvät palvelimella hallitusta istuntodatasta varmistaen vankan pääsynhallinnan ja tietoturvan.

• Yksittäiset palvelimet tai pienimittakaavaiset järjestelmät

  Sisäiset työkalut tai pienimittakaavaiset sovellukset ilman suuria skaalautuvuustarpeita menestyvät yksinkertaisella istuntohallinnalla käytön helppouden ja luotettavuuden vuoksi.

Milloin käyttää JWT-todennusta#

JWT-todennus on paremmin soveltuva sovelluksiin, jotka priorisoivat skaalautuvuutta, tehokkuutta ja hajautettuja järjestelmiä. Se on erityisen hyödyllinen tilattomissa vuorovaikutuksissa asiakkaiden ja palvelimien välillä. Harkitse tunnuspohjaista todennusta seuraaviin:

• Kerta kirjautuminen (SSO)

  JWT:t ovat täydellisiä kerta kirjautumiseen, mahdollistaen käyttäjän todentautumisen kerran ja saumattoman pääsyn useisiin palveluihin tai sovelluksiin saman tunnuksen avulla. Jaa yksityiskohtainen selitys turvallisista pilvipohjaisista sovelluksista käyttämällä OAuth 2.0 ja OIDC JWT-muodossa sekä pääsytunnuksille että ID-tunnuksille.

• Mobiilisovellukset

  Mobiilisovellukset suosivat usein JWT:t todennukseen, koska tunnuksia voidaan turvallisesti tallentaa laitteelle ja lähettää jokaisella API-pyynnöllä. Tutustu JWT-todennuksen nopeaan integrointiin Androidille / iOS:lle.

• Mikropalveluarkkitehtuurit

  Mikropalveluympäristöissä JWT:t mahdollistavat jokaisen palvelun itsenäisesti validoida tunnuksen ilman tukeutumista keskitettyyn istuntotallennukseen, turva ja tehokkuus mielessä.

• Monialueen todennus

  JWT:t loistavat tilanteissa, jotka sisältävät useita alueita tai alatunnuksia (esim. api.example.com, dashboard.example.com ja docs.example.com). Toisin kuin evästeet, JWT:t mahdollistavat todennuksen alueiden välillä ilman ylimääräisiä riippuvuuksia.

• API:t ja verkkopalvelut

  RESTful API:t ja verkkopalvelut käyttävät yleisesti JWT:eitä todennukseen, koska ne ovat kevyitä, siirrettäviä ja eliminoivat tarpeen palvelinpuolen istuntotallennuksen hallinnalle. Opi lisää kone-kone -todennuksesta tilanteissa, joissa sovelluksesi täytyy kommunikoida suoraan resurssien kanssa.

Hyvät käytännöt JWT-todennuksen kokemuksen parantamiseksi#

JWT-todennus on hyvä työkalu, mutta se voi tuoda mukanaan haasteita, jotka vaikuttavat käyttäjäkokemukseen. Logto tarjoaa helpon ja luotettavan ratkaisun ylittääksesi nämä esteet, tehden siitä parhaan valinnan turvalliselle ja tehokkaalle todennukselle.

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

Yksi yleinen ongelma JWT-todennuksessa on varmistaa asianmukainen käyttäjän uloskirjautumiskokemus. Logto yksinkertaistaa tätä prosessia valmiin SDK:nsä avulla.

• Puhtaalla tunnuksilla ja paikallisilla istunnoilla asiakaspuolella ja ohjaamalla käyttäjiä Logton istunnon lopetuspisteeseen, voit helposti päätellä istuntoja sekä asiakassovelluksessa että palvelimella.
• Lisäksi Logto tukee taustakanavan uloskirjautumista, jolloin AuthServer voi ilmoittaa kaikille asiakassovelluksille, jotka jakavat saman istunnon, kun käyttäjä kirjautuu ulos.

Tämä varmistaa johdonmukaisen ja turvallisen istuntohallinnan ekosysteemissäsi. Lisätietoja uloskirjautumisen käsittelemisestä.

Käyttäjän lupamuutosten käsittely#

Reaaliaikaisten käyttäjän lupamuutosten hallinta JWT:n kanssa voi myös olla hankala. Koska JWT:t ovat luonteeltaan tilattomia, kaikki päivitetyt luvat tai roolit eivät ehkä astu voimaan ennen tunnuksen vanhenemista. Logto tarjoaa strategioita näiden tehokkaaseen käsittelyyn:

• Käyttäjän lupien vähentämiseksi: Käytä lyhyitä pääsytunnuksen vanhenemisaikoja tai tarkista dynaamisesti oikeudet API-kutsun kautta.
• Käyttäjän uusien lupien lisäämiseksi: Päivitä AuthServer sisällään uutta lupan laajuutta ja uudelleenvaltuut luvat käyttäjille soveltaaksesi näitä muutoksia.

Nämä ratkaisut auttavat pitämään käyttöoikeudet ajan tasalla ja varmistavat turvallisemman, herkemmän järjestelmän. Lisätietoja lupamuutosten käsittelemisestä.

Logto, joka on skaalautuva identiteetin hallintainfrastruktuuri, tarjoaa täydellisen identiteettiratkaisun sekä pilvipalveluversion että avoimen lähdekoodin version.