## Johdanto [OpenID Connect -protokolla](https://openid.net/specs/openid-connect-core-1_0.html), joka tunnetaan myös nimellä OIDC, on noussut laajalti käytetyksi standardiksi, joka tarjoaa perustavanlaatuisen viitekehyksen identiteetinhallinnalle. Se on todennuskerros tunnetun OAuth 2.0 -protokollan päälle rakennettuna. Kun taas OAuth 2.0 on pelkästään resurssien valtuutusta varten, OIDC on protokolla, joka vakioi ja vahvistaa asiakastodennuksen uuteen esitellyn ID-tokenin avulla. Hetkinen... Olet ehkä kuullut refresh-tokeneista ja pääsytokeneista OAuth-ajalla, ja nyt OIDC:ssä on uusi käsite? Ymmärrätkö todella näiden tokenien erot? [Logto](https://logto.io/), kattava asiakasidentiteetin ja pääsynhallinnan (CIAM) ratkaisumme, on rakennettu OIDC-protokollan päälle. Yhteisössämme yksi käyttäjiemme yleisimmistä kysymyksistä on: > **Mitkä ovat erot refresh-tokenin, pääsytokenin ja ID-tokenin välillä?** Joten tässä artikkelissa sukellamme OIDC-tokenien keskeisiin näkökohtiin ja valaistaan, miten Logto parantaa kehittäjäkokemusta kokonaisuudessaan. Kokeile Logto Cloudia 5 minuutissa ## Aloitetaan käytännön tilanteella Kuvittele työskenteleväsi tyypillisessä asiakas-palvelin-sovelluksessa, ja ne kommunikoivat keskenään RESTful API:en kautta. Haluat pitää suurimman osan API:sta yksityisinä, sallien vain valtuutettujen asiakkaiden pääsyn. Sitten saatat kohdata ensimmäisen kysymyksen: ### Minkä tyyppistä tokenia tarvitsen API:n suojaamiseen? Nopea vastaus on: pääsytoken. OIDC:ssä kutakin suojattua API:a käsitellään resurssina. Pääsytoken on varsinainen tunniste, jonka asiakas välittää palvelimelle pyytäessään API-resurssia, tavallisesti pyyntöotsikon kautta. Palvelinpuolella, aina kun pyyntö saapuu, palvelimen tarvitsee vain tarkistaa, sisältääkö saapuva pyyntö kelvollisen pääsytokenin. Pääsytokenit ovat lyhytkestoisia tunnisteita, jotka antavat valtuutuksen pääsyyn suojattuihin resursseihin käyttäjän puolesta. Kun käyttäjä todentaa onnistuneesti käyttämällä OIDC:tä, valtuutuspalvelin myöntää pääsytokenin. Tämä token sisältää tietoja käyttäjästä, hänen oikeuksistaan ja voimassaolonsa kestosta. Token lähetetään sitten jokaisen seuraavan pyynnön mukana resurssipalvelimelle, jolloin palvelin voi vahvistaa käyttäjän identiteetin ja valtuuttaa pääsyn pyydettyihin resursseihin. Saatat kuitenkin pohtia: Jos asiakassovellukseni voi saada kelvollisen pääsytokenin onnistuneen kirjautumisen jälkeen ja käyttää pääsytokenia palvelimen API:iden pyytämiseen, eikö se riitä? Miksi tarvitsen refresh-tokeneita ja ID-tokeneita? Todellakin, hyvä kysymys, ja selitetään se askel askeleelta. ### Miksi tarvitsemme refresh-tokeneita? Vaikka teknisesti pääsytokenit täyttävät järjestelmän toiminnan vähimmäisvaatimukset, kuitenkin turvallisuussyistä pääsytokenien voimassaoloaika on yleensä hyvin lyhyt (tyypillisesti tunti). Joten kuvittele, jos meillä olisi vain pääsytokeneita, käyttäjien olisi re-todennettava aina, kun pääsytoken vanhenee. Nykyajan yksisivuisille verkkosovelluksille ja erityisesti mobiilisovelluksille usein kirjautuminen ulos on melko kivulias käyttäjäkokemus, vaikka yritämme vain suojella heidän käyttäjäturvallisuuttaan. Siksi tarvitsemme tasapainon tokeniturvallisuuden ja käyttäjäystävällisyyden välillä. Siksi OIDC esittelee refresh-tokeneita. Refresh-token on pidempiaikainen token, jota käytetään uusien pääsytokenien saamiseen ilman, että käyttäjän tarvitsee re-todentaa. Se on kuin avain uusien avainten saamiseen. Refresh-tokenit käytetään, kun pääsytoken vanhenee tai se pitää uusia. Niillä on pidempi voimassaoloaika kuin pääsytokeneilla, usein päivistä viikkoihin tai jopa kuukausiin. ### Miksi refresh-tokeneilla voi olla pidempi kestoaika? Pääsytokeneita käytetään API-resurssien käyttöön, joten niiden lyhyt elinikä auttaa vähentämään riskiä, että ne vuotavat tai joutuvat vääriin käsiin. Toisaalta, koska refresh-tokeneita käytetään vain uusien pääsytokeneiden vaihtamiseen, niitä käytetään harvemmin kuin pääsytokeneita ja siten altistumisriski on pienempi. Siksi pidemmän voimassaoloajan katsotaan olevan hyväksyttävää refresh-tokeneille. ### Refresh-tokenin turvallisuuden varmistaminen Koska myös refresh-token tallennetaan asiakaspuolelle, niiden vaarantumattomuuden varmistaminen on haastavaa, erityisesti julkisille asiakkaille, kuten yksisivuisille verkkosovelluksille (SPA). Logtossa refresh-tokeneilla on automaattinen [rotaatiomekanismi](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13#section-4.12) oletuksena käytössä, mikä tarkoittaa, että valtuutuspalvelin myöntää uuden refresh-tokenin, kun se täyttää kriteerit: - Yksisivuiset sovellukset: Tunnistettu lähettäjärajoittamattomiksi asiakkaiksi, nämä sovellukset vaativat refresh-tokenin rotaatiota. Refresh-tokenin ajan elää (TTL) ei voida määrittää. - Natiivisovellukset ja perinteiset verkkosovellukset: Refresh-tokenin rotaatio on luonnostaan käytössä, ja se uusiutuu automaattisesti saavuttaessaan 70 % sen TTL:stä. [Lue lisää](https://docs.logto.io/docs/references/applications/#rotate-refresh-token) Vaikka sinulla on edelleen mahdollisuus poistaa refresh-tokenin rotaatio käytöstä sovelluksen yksityiskohtaisella sivulla ylläpitäjän konsolissa, on erittäin suositeltavaa säilyttää tämä suojauskeino. ### ID-tokenin olemus [ID-tokeni](https://openid.net/specs/openid-connect-core-1_0.html#IDToken) sallii asiakkaan saada perustietoa käyttäjästä pyytämättä palvelinta. ID-tokeni on uusi tokenityyppi, jonka OIDC esitteli, ja se pitää sisällään välimuistissa olevia käyttäjän todennustietoja, parantaen suorituskykyä ja loppukäyttäjäkokemusta. Toisin kuin pääsytokenit, jotka on tarkoitettu vain resurssipalvelimen ymmärrettäväksi, ID-tokenit ovat asiakasystävällisiä. Kun asiakas tekee OIDC-tokenvaihtopyynnön, se voi pyytää ID-tokenin yhdessä pääsytokenin kanssa. ID-token on JSON Web Token (JWT), joka sisältää käyttäjäsettejä, kuten käyttäjänimi, sähköposti, avatar-kuva jne. Se on valtuutuspalvelimen allekirjoittama ja sen voi vahvistaa ja dekoodata asiakas offline-tilassa. Tämä on erityisen hyödyllistä nykyaikaisille yksisivuisille verkkosovelluksille ja mobiilisovelluksille, joissa asiakas voi välimuistiin tallentaa ID-tokenin ja käyttää sitä määrittääkseen käyttäjän todennustilan, mikä suuresti auttaa suorituskykyä ja käyttäjäkokemusta kokonaisuudessaan. On myös tärkeää huomata, että ID-tokeneita ei käytetä pääsyyn suojattuihin resursseihin; pääsytokenit täyttävät tuon roolin. Logtossa käytämme myös ID-tokenia SDK:ssamme auttaaksemme määrittämään todennustilan asiakaspuolella. Esimerkiksi [JS SDK:ssamme](https://docs.logto.io/docs/references/applications/#rotate-refresh-token) voit nähdä: ```tsx const isAuthenticated = Boolean(await this.getIdToken()); ``` Kuten edellä mainittiin, asiakkaan SDK:n `isAuthenticated`-lippu on vain asiakkaan välimuistiin tallennettu tila. Todellinen todennustila on edelleen määräydy kantapisteen perusteella, tarkistamalla refresh ja pääsytokenit. Tarjoamme myös `getUserClaims()`-funktion SDK:ssamme auttaaksemme sinua dekoodaamaan ID-tokenin ja saamaan käyttäjäsettejä. Kuitenkin välimuistitila ei päivity ennen kuin käyttäjä kirjautuu uudelleen sisään. Jos haluat hakea reaaliaikaisia käyttäjätietoja OIDC-palvelimelta, käytä `fetchUserInfo()` sen sijaan. ## Logton edut ja ominaisuudet Logto on rakennettu tiukasti noudattaen OIDC-protokollaa, samalla kun se tarjoaa lisäominaisuuksia ja etuja kehittäjille ja yrityksille: 1. Kätevät SDK:t: Logto SDK:t yksinkertaistavat tokenien hallintaa sinulle. Sinun ei tarvitse tallentaa refresh-tokenia ja pääsytokenia manuaalisesti itse. Kutsu vain `getAccessToken()` joka kerta ja SDK yrittää aina käyttää tallennettua pääsytokenia uudelleen tai automaattisesti uusia sen, jos se on vanhentunut. 2. Refresh-tokenin rotaatio: Logto vahvistaa refresh-tokenin rotaatiomekanismin varmistaakseen, että refresh-tokenisi uusitaan aina sen kulutuksen jälkeen, mikä vähentää riskiä, että se vuotaa tai joutuu vääriin käsiin. Vaikka voitkin poistaa sen käytöstä hallintakonsolissa, mutta on ehdottomasti suositeltavaa säilyttää se käytössä. 3. Optimoitu suorituskyky: ID-tokenien avulla voit aina saada perustietoa käyttäjästä pyytämättä palvelinta. Hyödynnä `isAuthenticated`-tilaa ja `getIdTokenClaims()`-funktiota, jotka Logto SDK:t tarjoavat käyttäjäntunnustuksen tarkistamiseen ja käyttäjäsettien dekoodaamiseen asiakaspuolella. 4. Parannettu turvallisuus: Logto vahvistaa turvalliset yhteydet asiakkaan ja valtuutuspalvelimen välillä käyttämällä HTTPS:ää ja TLS:ää. Tämä turvaa tokenisi mahdolliselta varkaudelta valtuuttamattomilta osapuolilta ja takaa järjestelmäsi turvallisuuden. ## Yhteenveto OIDC-protokollassa Refresh-tokenit, pääsytokenit ja ID-tokenit toimivat yhdessä tarjoten turvallisen ja saumattoman käyttäjän todennuksen. - Refresh-tokenit poistavat käyttäjän puuttumisen uusien pääsytokenien saamiseen. - Pääsytokenit antavat valtuutuksen pääsyyn suojattuihin resursseihin. - ID-tokenit tarjoavat välimuistissa olevan käyttäjätiedon asiakkaalla, parantaen suorituskykyä. Näiden tokenien roolin ja merkityksen ymmärtäminen on ratkaisevan tärkeää kehittäjille, jotka toteuttavat OIDC-todennusta sovelluksiinsa. Valitsemalla Logton, kehittäjät ja yritykset voivat vapauttaa täyden potentiaalin tällaisista OIDC-ominaisuuksista, integroida vankkoja ja turvallisia todennusjärjestelmiä, jotka suojaavat käyttäjätietoja ja tarjoavat saumattoman käyttäjäkokemuksen. Kokeile Logtoa tänään