Tutkii OpenID Connect -kokoonpanon avainkenttiä ja käytännön sovelluksia.
Nykyajan digitaalisessa maailmassa todentaminen on keskeinen osa verkkosivustojen ja sovellusten suojaamista. OpenID Connect (OIDC), todentamiskerros, joka rakentuu OAuth 2.0 -protokollan päälle, tarjoaa standardoidun ja yksinkertaisen tavan todentaa henkilöllisyyksiä.
OIDC:n asianmukainen integroiminen voi kuitenkin olla pelottavaa, erityisesti uusille käyttäjille. Hyvä lähtökohta on usein OIDC:n kokoonpanotiedosto, joka löytyy yleensä URL-osoitteesta {authServerUrl}/.well-known/openid-configuration ja sisältää kaikki tarvittavat tiedot OIDC-palveluiden toteuttamiseen.
Tämä opas pyrkii selventämään tämän kokoonpanon keskeisiä kenttiä, auttaen kehittäjiä ymmärtämään niiden merkityksen ja käytännön sovellukset, jotta OIDC voitaisiin paremmin integroida projekteihin.
OIDC-kokoonpano on JSON-tiedosto, joka näyttää esimerkiksi seuraavalta:
Seuraavaksi perehdymme syvällisemmin joihinkin avainkohtiin.
Kun OIDC-palveluita integroidaan, ensimmäinen vaihe on yleensä käyttäjien sisäänkirjautumispyyntöjen käsittely sovelluksessa. Tämä prosessi sisältää käyttäjien uudelleenohjaamisen auktorisointipalvelimen authorization_endpoint-kohtaan. Tämä päätepiste on palvelimen osoite, johon auktorisointipyynnöt lähetetään, ja se ohjaa käyttäjiä kirjautumissivulle tunnistautumaan.
Kun pyyntö authorization_endpoint-kohtaan tehdään, se on konfiguroitava lisäkyselyparametreilla jokaista valtuutusta kohden:
response_type: Määrittelee palautuvan valtuutuksen tyypin. Tämä sisältää yleensä "code" (auktorisointikoodivirtaa varten), "token" (implisiittivirtaa varten) ja "id_token token" tai "code id_token" (hybridivirtaa varten), jotka löytyvät OIDC-konfiguraation response_types_supported-kentästä.client_id: Ainutlaatuinen tunniste, joka on myönnetty sovellukselle auktorisointipalvelimen toimesta sovelluksen rekisteröinnin yhteydessä. Tämä tunnus on auktorisointipalvelimen käyttämä asiakassovelluksen tunnistamiseen pyynnön alullepanijana.scope: Määrittelee pyydetyn pääsyn laajuuden, määrittäen käyttäjän resurssit tai tiedot, jotka ovat saatavilla. Yleisiä laajuuksia ovat "openid" (pakollinen), "profile" ja "email", muiden muassa. Löydät tuetut laajuudet OIDC-konfiguraation scopes_supported-kentästä; eri laajuudet tulee erottaa välilyönneillä.redirect_uri: Kirjautumisen tai valtuutuksen jälkeen auktorisointipalvelin uudelleenohjaa käyttäjän sovelluksen antamaan URI:iin. Tämä URI:n on ehdottomasti vastattava sovelluksen rekisteröinnin yhteydessä annettua URI:a.state: Satunnaisesti luotu merkkijono, jota käytetään suojaamaan asiakasta ristikkäisten pyyntöjen väärentämiseen kohdistuvilta hyökkäyksiltä. Valtiollinen yhdenmukaisuus valtuutuspyynnön ja palautuksen välillä on säilytettävä turvallisuuden varmistamiseksi.Nämä parametrit antavat kehittäjille mahdollisuuden tarkasti kontrolloida OIDC-valtuutuspyyntöjen käyttäytymistä, varmistaen, että ne ovat turvallisia ja vastaavat sovelluksen tarpeita.
Kun pyyntö authorization_endpoint-kohtaan on suoritettu ja todentaminen on läpäisty, käyttäjät ohjataan määriteltyyn redirect_uri-kohtaan, johon sisältyy erittäin tärkeä kyselyparametri—code. Tämä valtuutuskoodi annetaan auktorisointipalvelimen toimesta ja on tulos siitä, että käyttäjä on todentanut ja valtuuttanut sovelluksen pääsemään heidän tietoihinsa auktorisointipalvelimella.
token_endpoint on palvelimen päätepiste, jota auktorisointipalvelin käyttää edellä mainitun valtuutuskoodin vaihtamiseksi käyttöoikeus- ja uusimistunnuksiin. OAuth 2.0 -auktorisointikoodivirrassa tämä vaihe on kriittinen, koska se käsittelee saadun valtuutuskoodin muuntamisen varsinaisiksi käyttöoikeustunnuksiksi, joita sovellus voi käyttää käyttäjän suojattuihin resursseihin.
Näin valtuutuskoodi vaihdetaan käyttöoikeustunnuksiin (huomaa, että tämä esimerkki käyttää client_secret_post -todentamismenetelmää. Muiden tuettujen todentamismenetelmien osalta viittaa myöhemmin
token_endpoint_auth_methods_supportedTässä koodissa lähetämme ensin pyynnön token_endpoint-kohtaan POST-menetelmää käyttäen. Sisältötyyppi on asetettu application/x-www-form-urlencoded-muotoon, jota useimmat auktorisointipalvelimet vaativat. Pyyntörunko sisältää seuraavat parametrit:
redirectUri-kautta sen jälkeen, kun käyttäjä on suorittanut valtuutuksen."authorization_code", joka osoittaa, että käyttöoikeustunnus saadaan valtuutuskoodin kautta.Tämä funktio suoritetaan asynkronisesti ja palauttaa JSON-objektin, joka sisältää käyttöoikeustunnuksen, jota sovellus voi käyttää pyytämään käyttäjän tietoja tai suorittamaan muita toimenpiteitä.
userinfo_endpoint on palvelimen päätepiste, jota auktorisointipalvelin käyttää saadakseen yksityiskohtaisia tietoja todistetuista käyttäjistä. Kun käyttäjät ovat onnistuneesti valtuuttaneet ja saaneet käyttöoikeustunnukset token_endpoint-kohdan kautta, sovellus voi pyytää tätä päätepistettä saadakseen käyttäjän profiilitiedot, kuten käyttäjänimen ja sähköpostiosoitteen. Saatavien tietojen laajuus riippuu käyttäjän todentamispyyntön yhteydessä määrittelemästä scope-arvosta.
Tässä funktiossa käytämme ensin GET-menetelmää pyytääksemme userinfo_endpoint-kohtaa, sisältäen Authorization-kentän pyynnön otsikossa, joka on koostettu token_type-arvosta ja accessToken-koodista. Tämä on standarditoimenpide OAuth 2.0 -määrittelyn mukaisesti, varmistaen käyttäjätietojen turvallisen noudon. Lisäksi käyttöoikeustunnuksen kautta saavutetun käyttäjätiedon laajuus riippuu täysin valtuutuspyynnön alussa valituista scope-parametrien arvoista. Esimerkiksi, jos käytetään sähköposti-laajuutta, vastaus tulisi sisältää käyttäjän sähköpostiosoitteen.
Issuer tunnistaa auktorisointipalvelimen URL-osoitteen, kun taas jwks_uri tarjoaa URI:n JSON Web Key Setille (JWKS), joka on joukko julkisia avaimia, joita käytetään JWT-allekirjoitusten vahvistamiseen. JWT:n issuer- ja allekirjoitusvahvistus ovat perustavanlaatuisia vaiheita tunnusten turvallisuuden varmistamisessa, mutta todellisissa tilanteissa vahvistusprosessi sisältää tyypillisesti myös tunnuksen voimassaoloajan, yleisön, valtuutuksen laajuuden ja muita tärkeitä kenttiä.
Seuraava koodi demonstroi, kuinka käyttää issuer-arvoa ja jwks_uri-URLiä yhdessä JWT:n varmentamiseen:
claims_supported ja scopes_supported -kentät ilmoittavat arvotukiasemat (claims) ja pääsyoikeuden laajuudet (scopes), joita auktorisointipalvelin tukee. Ne auttavat asiakkaita ymmärtämään, mitkä käyttäjäominaisuudet ja pääsyoikeuden laajuudet auktorisointipalvelin tukee, mikä mahdollistaa asiakkaille tehokkaiden valtuutuspyyntöjen ja vastausten purkamisen.
Kun valtuutuspyyntöä rakennetaan, asiakkaat voivat määrittää halutun scope-arvon sovelluksen tarpeiden perusteella. Scope määrittelee resurssit ja toiminnot, joihin asiakas pyytää pääsyä, kuten openid, email, profile ja muut.
On tärkeää huomata, että kussakin valtuutuspyynnössä saatavien toimintaperusteiden erityiset väittämät vaihtelevat sen mukaan, millä scope-arvoilla käyttäjä määrittelee alussa. Esimerkiksi, sähköposti-laajuuden käyttö myöntää pääsyn käyttäjän sähköpostiosoitteeseen, kun taas puhelimen käytön mahdollistaa käyttäjän puhelinnumeron saannin. Asiakkaiden tulisi siis huolellisesti valita sovelluksen tarpeisiin soveltuva scope, varmistaen, että tarvittavat käyttäjäominaisuudet voidaan palauttaa:
token_endpoint_auth_methods_supportedToken endpointia käytettäessä, yleisiä todentamismenetelmiä ovat client_secret_post, client_secret_basic ja client_secret_jwt.
client_secret_post: Asiakas käyttää asiakastunnistettaan ja asiakassalasanaan muodostaakseen lomakekoodatun rungon, joka lähetetään osana pyyntörunkoa. Olemme jo nähneet esimerkin tästä menetelmästä token_endpoint-osassa yläpuolella.
client_secret_basic: Asiakas käyttää asiakastunnistettaan ja asiakassalasanaan muodostaakseen perusautentikointipään, joka lisätään pyyntöotsikkoon.
client_secret_jwt: Asiakas käyttää JWT:tä (JSON Web Token) asiakastodisteena todentamiseen. Tämä JWT sisältää asiakastunnisteen ja joitakin lisämetatietoja, ja se on allekirjoitettu käyttäen asiakassalasanaa. Kun palvelin on vastaanottanut pyynnön, auktorisointipalvelin vahvistaa asiakkaan identiteetin varmentamalla JWT:n allekirjoituksen.Käytännön sovelluksissa asiakkaiden on valittava sopiva todennusmenetelmä auktorisointipalvelimen tukemien menetelmien perusteella ja varmistettava, että todennustiedot lisätään oikein pyyntöön turvallisesti vaihtaakseen valtuutuskoodin käyttöoikeustunnuksiin.
Olemme nyt tutkineet OIDC-kokoonpanon avainkohtia keskittyen niiden tarkoituksiin ja sovelluksiin. Näiden yksityiskohtien ymmärtäminen auttaa syventämään ymmärrystä OpenID Connectista, mikä mahdollistaa sen tehokkaamman integroinnin ja hyödyntämisen projekteissa. Tämän tiedon avulla olet paremmin varustautunut hyödyntämään OIDC:n täyttä potentiaalia turvallisempien ja tehokkaampien käyttäjätodennusratkaisujen tarjoamiseksi.
Logto, OIDC:hen perustuvana todennuspalveluna, tarjoaa kokonaisvaltaisen paketin SDK:ita eri kielillä sekä lukuisia integrointitutoriaaleja, joiden avulla voit saumattomasti integroida OAuth / OIDC-kirjautumiset sovelluksiisi vain muutamassa minuutissa. Jos etsit luotettavaa ja helppokäyttöistä OIDC-palvelua, kokeile Logtoa tänään!