Täydellinen opas OIDC-palvelimen integroimiseen projektiisi

Saatat kohdata tilanteen, jossa tarvitset keskitettyä todennus- ja valtuutusjärjestelmää, eli identiteetin hallintaa (IAM) tai identiteettipalveluntarjoajaa (IdP). Joskus ihmiset lisäävät sanan liiketoiminnan kuvaamiseksi, kuten Asiakas IAM ja Työvoiman IAM.

Laitetaan nämä hienot nimet hetkeksi sivuun. IAM:n tarve voi syntyä, koska sovelluksesi kasvaa tai suunnittelet kovien töiden delegoimista toimittajalle alusta alkaen. Joka tapauksessa olet saavuttamassa pisteen, jossa identiteettijärjestelmä täytyy ottaa käyttöön projektissasi.

OAuth 2.0:n suosion huomioon ottaen OpenID Connect (OIDC) on luonnollinen valinta monille kehittäjille. Koska OIDC on todennuskerros, joka on rakennettu OAuth 2.0:n päälle, saatat tuntea olosi tutuksi, kun alat työskennellä OIDC:n kanssa. Aloitetaan!

Mikä on OIDC-palvelin ja miksi minun pitäisi integroida OIDC-palvelin?#

OIDC-palvelin tai identiteettipalveluntarjoaja on keskitetty järjestelmä, joka hallinnoi käyttäjien todennusta ja valtuutusta. Kuten keskustelimme Miksi tarvitset keskitetyn identiteettijärjestelmän monisovellusliiketoiminnalle, keskitetty identiteettijärjestelmä tarjoaa monia etuja.

Oletetaan, että projektisi alkaa yksinkertaisella verkkosovelluksella ja sillä on sisäänrakennettu todennus:

Kun projektisi kasvaa, sinun täytyy lisätä mobiiliversio:

Käyttäjillä olisi huono kokemus, jos heidän pitäisi luoda tili jokaiselle sovellukselle. Koska aloitit verkkosovelluksella, annat mobiilisovelluksen kommunikoida verkkosovelluksen kanssa todennusta varten:

Nyt uusi API-palvelu otetaan käyttöön. Koska se on palvelu maksaville käyttäjille, sinun täytyy varmistaa, että käyttäjä on todennettu ja valtuutettu käyttämään palvelua. Tämän saavuttamiseksi voit välittää palvelun verkkosovelluksen kautta:

Tai käytä jonkin token-tekniikkaa käyttäjän todennukseen ja validoi token keskustelemalla palvelussa verkkosovelluksen kanssa. Siten mobiilisovellus voi käyttää palvelua suoraan:

Asiat alkavat mennä sekaisin. Siksi päätät jakaa todennus- ja valtuutuslogiikan erilliseen palveluun:

Uudelleenjärjestelyprosessi voi olla kivulias. Saatat huomata, että sen monimutkaisuus kasvaa eksponentiaalisesti, kun lisäät projektiin enemmän sovelluksia ja palveluita. Mikä vielä pahempaa, saatat joutua ylläpitämään useita todennustapoja, kuten salasanattomia kirjautumisia, sosiaalista kirjautumista, SAML:ia jne.

Tästä syystä meidän on parasta ottaa identiteettipalveluntarjoaja käyttöön alusta alkaen, kun sinulla on suunnitelma laajentaa projektiasi.

Parhaat käytännöt OIDC-palvelimen integroimiseksi#

Löydä OIDC-palveluntarjoaja#

Markkinoilla on monia OIDC-palveluntarjoajia. Voit valita yhden vaatimustesi ja mieltymystesi mukaan. Kunnan palveluntarjoaja on OIDC-mukainen, se toimii samalla tavalla projektissasi.

Mitä "subject", "client" ja "audience" tarkoittavat OIDC:ssä?#

Yksinkertaistaaksemme käsitettä, voimme ajatella, että kohde on entiteetti, joka pyytää pääsyä yleisöön asiakkaan kautta.

Katsotaanpa joitakin tyypillisiä tilanteita:

1. Käyttäjä napsauttaa kirjautumispainiketta verkkosovelluksessa#

Perinteisessä ja palvelinpuolen renderöidyssä verkkosovelluksessa frontend ja backend ovat yhdistettyjä. Oletetaan, että verkkosovellus palvelee sekä frontendiä että backendiä:

• Kohde: Käyttäjä
• Yleisö: OIDC-palvelin
• Asiakas: Verkkosovellus

Se saattaa näyttää vastoin intuitiota, että yleisö on OIDC-palvelin. Itse asiassa se on avain lopputuloksena SSO (Single Sign-On) -kokemukseen loppukäyttäjille. Katsotaan yksinkertaistettu sekvenssikaavio valtuutuskoodi-virrasta:

code on kertakäyttöinen koodi, joka voidaan vaihtaa eri tokeneiksi, kuten pääsytokeniksi, ID-tokeniksi ja päivitystokeniksi. On ok, jos et ymmärrä kaikkia näitä tokeneita tällä hetkellä. Kun etenemme, saat paremman käsityksen niistä.

Edellä olevassa tapauksessa käyttäjän ei tarvitse kirjautua uudelleen, kun hän siirtyy toiseen sovellukseen, koska käyttäjä (kohde) on jo todennettu OIDC-palvelimen (yleisön) kanssa.

2. Käyttäjä käyttää yksisivuista sovellusta#

Yksisivuisessa sovelluksessa (tai mobiilisovelluksessa) frontend ja backend ovat erillisiä. Oletetaan, että backend on API-palvelu:

• Kohde: Käyttäjä
• Yleisö: API-palvelu
• Asiakas: Yksisivuinen sovellus (SPA)

Yksinkertaistettu sekvenssikaavio valtuutuskoodi-virralla:

Koska API-palvelu on ei-interaktiivinen, SPA:n on käytettävä pääsytokenia API-palvelun kanssa yleisönä (tokenin aud).

Miksi OIDC-palvelin on edelleen yleisö?

Teknisesti voit poistaa OIDC-palvelimen yleisölistalta. Useimmissa tapauksissa tarvitset käyttäjätietoja OIDC-palvelimelta (joka vaatii OIDC-palvelimen olevan yleisö), joten on parempi aina sisällyttää OIDC-palvelin yleisölistaan, kun se sisältää käyttäjävuorovaikutusta.

Hetki, sanoitko, että voimme saada useita yleisöjä valtuutuspyynnössä?

Tarkalleen! Muista, että OIDC on rakennettu OAuth 2.0:n päälle, on mahdollista hyödyntää RFC 8707: Resource Indicators for OAuth 2.0 valtuutuspyynnössä määrittääkseen useita yleisöjä. Se vaatii tukea sekä avustukselta että OIDC-palvelimelta. Logto tukee tätä ominaisuutta natiivisti.

3. Koneen välinen kommunikointi#

Oletetaan, että sinulla on palvelu A, joka tarvitsee soittaa palvelua B:

• Kohde: Palvelu A
• Yleisö: Palvelu B
• Asiakas: Palvelu A

Yksinkertaistettu sekvenssikaavio client credentials grantilla:

Kun palvelu B tarvitsee soittaa palvelua A, rooleja vaihdetaan yksinkertaisesti.

Yhteenveto#

• Kohde: Se voi olla käyttäjä, palvelu tai mikä tahansa entiteetti, joka tarvitsee pääsyä yleisöön.
• Asiakas: Se voi olla verkkosovellus, mobiilisovellus tai mikä tahansa entiteetti, joka aloittaa pyynnön tai toimii kohteen puolesta.
• Yleisö: Se voi olla palvelu, API tai mikä tahansa entiteetti, joka tarjoaa pääsyn kohteelle.

Mitä ovat pääsytokenit, ID-tokenit ja päivitystokenit?#

OIDC:ssä voi kohdata kolme tyyppistä tokenia:

• Pääsytokeni: Sitä käytetään pääsyyn yleisöön. Se voi olla JWT (JSON Web Token) tai epämääräinen tokeni (yleensä satunnainen merkkijono).
• ID-tokeni: OIDC-spesifinen token, joka sisältää käyttäjätietoja. Se on aina JWT. Asiakas voi purkaa tokenin saadakseen käyttäjätiedot.
• Päivitystokeni: Sitä käytetään saadakseen uuden sarjan tokeneita, kun pääsytokeni tai ID-tokeni vanhenee.

Yksityiskohtainen selitys näistä tokeneista löytyy Ymmärrä päivitystokenit, pääsytokenit ja ID-tokenit OIDC-protokollassa.

Yllä olevissa skenaarioissa 1 ja 2 termi valtuutuspyyntö viittaa pyyntöön saada sarja tokeneita tietyn avustuksen kautta.

Kun kaikki menee hyvin, sarja tokeneita palautetaan vaiheessa "signaation vaihto code avulla". Sarjan saatavilla olevat tokenit riippuvat useista tekijöistä, erityisesti scope-parametrista valtuutuspyynnössä. Yksinkertaisuuden vuoksi oletamme, että kaikki tokenit palautetaan sarjassa. Kun pääsytokeni vanhenee, asiakas voi käyttää päivitystokenia saadakseen uuden sarjan tokeneita ilman käyttäjävuorovaikutusta.

Skenaariossa 3 se on yksinkertaisempaa, koska asiakastodistusavustus palauttaa vain pääsytokenin.

Miten käsitellä useita yleisöjä OIDC:ssä?#

Saatat huomata, että vain yksi pääsytokeni palautetaan kerrallaan. Miten voisimme käsitellä tapausta, jossa asiakas tarvitsee pääsyä useisiin yleisöille?

On kaksi yleistä ratkaisua:

Määritä resource koodin vaihtopyynnössä#

Kun asiakas vaihtaa koodin tokeneihin, se voi määrittää resource-parametriin pyynnössä. OIDC-palvelin palauttaa pääsytokenin määritellylle yleisölle, jos se on saatavilla.

Tässä epävirallinen esimerkki:

Sitten OIDC-palvelin palauttaa pääsytokenin API_SERVICE-yleisölle, jos se on saatavilla.

Käytä päivitystokenia saadaksesi uuden pääsytokenin#

RFC 8707:n avulla asiakas voi jopa määritellä useita yleisöjä käyttämällä resource-parametriä useaan kertaan. Nyt, jos päivitystokenit ovat saatavilla asiakkaalla, asiakas voi määrittää yleisön resource-parametriin, kun päivitetään tokenia.

Tässä epävirallinen esimerkki:

Sillä on sama vaikutus kuin edellisellä ratkaisulla. Samalla muut myönnetyt yleisöt ovat edelleen käytettävissä tulevissa token-pyynnöissä.

Asiakkaan tunnistetiedot#

Voit myös käyttää resource-parametriä asiakastodistusavustuksessa määrittääksesi yleisön. Tässä avustuksessa ei ole ongelmaa usean yleisön kanssa, koska voit aina pyytää uutta pääsytokenia eri yleisölle yksinkertaisesti lähettämällä uuden token-pyynnön.

Suojaa API-palvelusi#

"API-palvelu" skenaariossa 2 ja "Palvelu B" skenaariossa 3 ovat yksi asia yhteistä: niiden täytyy validoida pääsytokeni määrittääkseen, onko pyyntö valtuutettu. Pääsytokenin muodosta riippuen validointiprosessi voi vaihdella.

• Epämääräinen tokeni: API-palvelun tarvitsee kutsua OIDC-palvelinta tokenin validointiin. OIDC-palvelin tarjoaa yleensä introspektiopisteen tätä tarkoitusta varten.
• JWT: API-palvelu voi validoida tokenia paikallisesti tarkistamalla allekirjoituksen ja väittämät tokenissa. OIDC-palvelin tarjoaa yleensä JSON Web Key Set (JWKS) -pisteen (jwks_uri) API-palvelulle allekirjoituksen tarkistamiseen.

Jos olet uusi JWT:ssä, voit viitata Mikä on JSON Web Token (JWT)?. Itse asiassa, yleensä ei ole tarpeen validoida allekirjoitusta ja väittää manuaalisesti, koska on monia kirjastoja, jotka voivat tehdä sen puolestasi, kuten jose Node.js:lle ja verkkoselaimille.

Väittämien tarkistaminen#

Lisäksi JWT-allekirjoituksen validoinnin lisäksi API-palvelun pitäisi aina tarkistaa väittämät tokenissa:

• iss: Tokenin myöntäjä. Sen pitäisi vastata OIDC-palvelimen myöntäjä-URL:ää.
• aud: Tokenin yleisö. Sen pitäisi vastata API-palvelun yleisöarvoa (yleensä kelvollinen URI).
• exp: Tokenin vanhenemisaika. API-palvelun pitäisi hylätä token, jos se on vanhentunut.
• scope: Tokenin laajuudet (lupat). API-palvelun pitäisi tarkistaa, onko tarvittava laajuus tokenissa.

Muut väittämät, kuten sub(kohde) ja iat (myönnetty tässä), ovat myös tärkeitä joissakin tapauksissa. Jos sinulla on lisäturvatoimenpiteitä, tarkista väitteet vastaavasti.

Valtuutus#

Yksi vastaamaton kysymys pysyy siellä: Miten määrittelemme, voidaanko scope (eli lupa) myöntää kohteelle?

Yksi kysymys johtaa kokonaan uuteen valtakuntaan valtuutuksia, jotka ovat tämän artikkelin ulkopuolella. Lyhyesti, on olemassa joitakin yleisiä lähestymistapoja, kuten RBAC (Role-Based Access Control) ja ABAC (Attribute-Based Access Control). Tässä on joitakin resursseja alkuun pääsemiseksi:

• RBAC ja ABAC: Tahralliset hallintamallit, jotka sinun pitäisi tietää
• Hallitseminen RBAC Logtossa: Kattava, todelliseen maailmaan perustuva esimerkki

Lopettavat muistiinpanot#

OIDC-palvelimen integroiminen projektiisi on iso askel. Se voi merkittävästi parantaa projektisi turvallisuutta ja skaalautuvuutta. Samaan aikaan se voi vaatia jonkin aikaa ymmärtääkseen käsitteitä ja komponenttien vuorovaikutusta.

Hyvän OIDC-palveluntarjoajan valitseminen, joka sopii vaatimuksiisi ja mieltymyksiisi, voi huomattavasti vähentää integrointiprosessin monimutkaisuutta, sillä palveluntarjoaja yleensä tarjoaa koko paketin, mukaan lukien OIDC-palvelin, valtuutusmekanismit, SDK:t ja yritysominaisuudet, joista saatat hyötyä tulevaisuudessa.

Toivon, että tämä opas auttaa sinua ymmärtämään OIDC-palvelimen integroinnin perusteet. Jos etsit yhtä, jolla aloittaa, suosittelen itsekkäästi Logtoa, identiteetti-infrastruktuurimme kehittäjille.