OpenID Connect (OIDC) protokolla on noussut laajalti käyttöön otetuksi identiteetinhallinnan standardiksi. Mutta ymmärrätkö todella näiden tunnusten roolit ja ominaisuudet?
OpenID Connect Protocol, joka tunnetaan myös nimellä OIDC, on muodostunut laajalti käyttöön otetuksi standardiksi tarjoten perustavan kehyksen identiteetin hallinnalle. Se on todennustaso, joka on rakennettu tunnetun OAuth 2.0 protokollan päälle. Kun OAuth 2.0 on pelkästään resurssien valtuutusta varten, OIDC on protokolla, joka vakioi ja vahvistaa asiakasvarmennusta uusien ID-tunnuksen avulla.
Hetkinen... Olet ehkä kuullut käyttö- ja päivitystunnuksista OAuth-aikana, ja nyt OIDC tuo mukanaan uuden käsitteen? Ymmärrätkö todella näiden tunnusten erot?
Aloitetaan käytännön skenaariosta.
Kuvittele, että kehität tyypillistä asiakas-palvelinsovellusta, ja ne kommunikoivat toistensa kanssa RESTful API:en kautta. Haluat pitää suurimman osan API:sta yksityisinä, sallien vain valtuutettujen asiakkaiden pääsyn. Tarvitset mekanismin asiakkaan todennukseen ja API-pyyntöjen valtuuttamiseen palvelimelle.
Ihannetapauksessa RESTful API:esi pitäisi olla tilattomia, mikä tarkoittaa, että palvelimen ei pitäisi tallentaa mitään asiakassessioita. Aina kun kelvollinen pyyntö saapuu, palvelimen pitäisi vain vastata pyydetyillä tiedoilla. Tässä tunnukset tulevat peliin. Joten, mitä tyyppiä tunnusta sinun pitäisi käyttää tällaisessa tapauksessa?
OAuth 2.0:ssa ja OIDC:ssä jokaista suojattua API:a käsitellään resurssina. Käyttötunnus on juuri se tunnus, jonka asiakas lähettää palvelimelle pyytäessään API-resurssia, tyypillisesti pyynnön otsikon kautta ja JWT muodossa.
Palvelinpuolella, aina kun pyyntö saapuu, palvelimen tarvitsee vain vahvistaa tuleeko pyyntö mukanaan kelvollinen käyttötunnus. Vahvistusprosessi yleensä käsittää JWT-tunnuksen purkamisen, allekirjoituksen ja voimassaoloajan tarkistamisen sekä laajuustiedon varmistamisen, että asiakkaalla on tarvittavat luvat.
Kuitenkin saatat pohtia: Jos asiakassovellukseni voi saada kelvollisen käyttötunnuksen onnistuneen kirjautumisen jälkeen, ja käyttää käyttötunnusta pyytääkseen palvelin API:a, eikö tämä riitä? Miksi tarvitsen muita tunnuksia?
Todellakin, kelvollinen kysymys, ja selvitetään asia askel askeleelta.
Vaikka teknisesti käyttötunnukset täyttävät vähimmäisvaatimukset järjestelmän toimimiselle, kuitenkin, turvallisuussyistä käyttötunnusten voimassaoloaika on yleensä hyvin lyhyt (tyypillisesti tunti). Joten kuvittele, jos meillä olisi vain käyttötunnuksia, loppukäyttäjien pitäisi todennettaa itsensä uudelleen aina kun käyttötunnus vanhenee. Nykyaikaisissa yhden sivun verkkosovelluksissa (SPA) ja erityisesti mobiilisovelluksissa usein tapahtuva uloskirjautuminen on melko kivulias käyttäjäkokemus, vaikka yritämme vain suojella heidän käyttäjäturvallisuuttaan.
Siksi tarvitsemme tasapainoa tunnusten turvallisuuden ja käyttäjän mukavuuden välillä. Siksi päivitystunnukset on otettu käyttöön.
Käyttötunnuksia käytetään pääsyyn API-resursseihin, joten niiden lyhytikäisyys auttaa lievittämään vuotamisen tai vaarantumisen riskiä. Toisaalta, koska päivitystunnuksia käytetään vain uusien käyttötunnusten vaihtamiseen, niitä ei käytetä yhtä usein kuin käyttötunnuksia ja näin ollen altistumisriski vähenee. Siksi pidemmän voimassaoloajan katsotaan olevan hyväksyttävä päivitystunnuksille.
Koska päivitystunnus on myös tallennettu asiakaspuolelle, niiden vaarantumattomuuden varmistaminen on haastavaa, erityisesti julkisille asiakkaille, kuten yhden sivun verkkosovelluksille (SPA) ja mobiilisovelluksille.
Logtossa päivitystunnuksilla on automaattinen kiertomekanismi, joka on oletuksena käytössä, mikä tarkoittaa, että valtuutuspalvelin myöntää uuden päivitystunnuksen kun se täyttää kriteerit:
Vaikka sinulla on mahdollisuus poistaa päivitystunnuksen kierto käytöstä hallintakonsolin sovellustietosivulla, on vahvasti suositeltavaa säilyttää tämä suojaustoimi käytössä.
ID-tunnus on OIDC:n ainutlaatuinen ominaisuus, joka tarjoaa todennetun käyttäjän identiteettitietoja.
Kun käyttötunnuksia käytetään pääsyyn suojattuihin resursseihin ja päivitystunnuksia käytetään uusien käyttötunnusten hankkimiseen, ID-tunnuksia käytetään tyypillisesti tallentamaan käyttäjätietoja asiakaspuolella, vähentäen tarvetta lisäpyynnöille valtuutuspalvelimelle käyttäjätietojen saamiseksi. Useimmissa tapauksissa, jopa voidaan sanoa, että ID-tunnuksen saaminen vastaa käyttäjän olevan todennettu.
OIDC-protokollassa päivitystunnukset, käyttötunnukset ja ID-tunnukset toimivat yhdessä tarjoten turvallisen ja saumattoman käyttäjätodennuksen.
Näiden tunnusten roolin ja merkityksen ymmärtäminen on ratkaisevan tärkeää kehittäjille, jotka toteuttavat OIDC-todennuksen sovelluksissaan.