Mikä on OIDC: Miksi sitä tarvitaan ja miten se toimii
Opi, mitä OIDC on, miksi sitä tarvitaan ja miten se toimii. Tutustu siihen, miten OIDC laajentaa OAuth 2.0:aa autentikointiin, ymmärrä sen keskeiset komponentit mukaan lukien ID-tunnukset, rajaukset ja käyttäjän tiedot -päätepiste.
OpenID Connect (OIDC) -määritelmä
OpenID Connect (OIDC) on identiteetin autentikointiprotokolla, joka on rakennettu OAuth 2.0:n päälle. Vaikka OAuth 2.0 tarjoaa vain valtuutuksen, OIDC lisää autentikointimahdollisuuksia tarjoten standardoidumman ratkaisun käyttäjän valtuutus- ja autentikointiskenaarioihin.
Yksinkertaistetusti: OIDC = Valtuutusprotokolla + Identiteetin autentikointi.
Miksi OIDC on tarpeen?
Ymmärtääksemme, miksi OIDC on tarpeen, tarkastellaan ensin OAuth 2.0:n keskeisiä käsitteitä ja työnkulkuja sekä sen käytännön sovellusten rajoituksia. Analysoimalla erityisiä skenaarioita näemme, miksi tarvitsemme OIDC:ta OAuth 2.0:n sijasta.
Keskeiset käsitteet ja OAuth 2.0:n valtuutusprosessi
OAuth 2.0 (Avoin valtuutus) on valtuutusprotokolla, joka antaa käyttäjille mahdollisuuden antaa kolmansille osapuolille pääsyn heidän resursseihinsa jakamatta tunnistetietojaan, kuten käyttäjänimiä ja salasanoja. Siihen liittyy neljä pääroolia:
- Resurssin omistaja: Käyttäjä, joka omistaa resurssit
- Resurssipalvelin: Palvelin, joka tallentaa käyttäjän resursseja
- Asiakas: Kolmannen osapuolen sovellus, joka pyytää pääsyä käyttäjän resursseihin
- Autorisointipalvelin: Palvelin, joka vahvistaa käyttäjän identiteetin ja myöntää pääsytunnuksia
Tyypillinen OAuth 2.0 -valtuutusprosessi toimii seuraavasti:
Kuten esitetty, OAuth 2.0 käsittelee pääsytunnusten myöntämistä kolmansille osapuolille käyttäjän resurssien käyttöön.
OAuth 2.0:n rajoitukset
OAuth 2.0 -protokolla keskittyy ainoastaan pääsytunnusten myöntämiseen. Resurssipalvelin vahvistaa nämä tunnukset ja palauttaa valtuutetut resurssit. Kuitenkin resurssipalvelin ei tiedä käyttäjän identiteettiä.
Tämä ei ollut merkittävä ongelma internet-ekosysteemin alkuvaiheessa.
Kuitenkin, kun alustat kuten Google, Facebook, Twitter ja Github kehittyivät, ne alkoivat tarjota rikkaita käyttäjäresursseja, joista tuli arvokkaita kolmansille osapuolille.
Vaikka OAuth 2.0 on erinomainen kolmansien osapuolten käyttäjien resurssien valtuuttamisessa, sillä on rajoituksia. Tyypillinen skenaario on: koska käyttäjätiedot ovat myös resurssi, kun kolmannen osapuolen sovellukset tarvitsevat pääsyä peruskäyttäjätietoihin, eri alustat (kuten Google, Facebook, Twitter) palauttavat käyttäjätiedot eri muodoissa, mikä aiheuttaa haasteita kehittäjille.
OIDC luotiin ratkaisemaan nämä haasteet.
Roolit OIDC:ssa
Jotta käyttäjien autentikointi olisi mahdollista OAuth 2.0:n päällä ja sen rajoitusten ratkaisemiseksi, OIDC esitti kolme roolia:
- Lopullinen käyttäjä (EU): Lopullinen käyttäjä, joka vastaa OAuth 2.0:n resurssin omistajaa
- Luottava osapuoli (RP): Luotettava osapuoli, joka vastaa OAuth 2.0:n asiakasta
- OpenID-palveluntarjoaja (OP): Identiteetin autentikointipalveluntarjoaja, joka vastaa OAuth 2.0:n autorisointipalvelinta ja resurssipalvelinta
OP on keskeinen rooli, joka tarjoaa sekä OAuth 2.0:n valtuutustoiminnallisuuden että käsittelee käyttäjätietoja erillisenä resurssina.
Miten OIDC toimii?
OIDC:n autentikointiprosessi on samanlainen kuin OAuth 2.0, mutta koska OP yhdistää autorisointi- ja resurssipalvelimen roolit, se palauttaa sekä pääsytunnuksen että ID-tunnuksen. ID-tunnus sisältää käyttäjän identiteettitiedot, ja RP voi vahvistaa käyttäjän identiteetin vahvistamalla ID-tunnuksen.
Tyypillinen työnkulku näyttää tältä:
Tämä standardisoi, miten käyttäjätietoja hankitaan eri alustoilla, eikä kolmansien osapuolten sovellusten tarvitse käsitellä alustakohtaisia eroja.
ID-tunnus OIDC:ssa
Kun käyttäjät valtuuttavat kolmansien osapuolten sovelluksia, OP palauttaa sekä OAuth 2.0 -pääsytunnuksen että JWT-muotoisen ID-tunnuksen. Tämä ID-tunnus sisältää käyttäjän identiteettitietoja, kuten käyttäjä-ID, käyttäjänimi, sähköpostiosoite ja avatar. RP voi vahvistaa käyttäjän identiteetin vahvistamalla ID-tunnuksen.
Koska se on JWT, ID-tunnus sisältää standardoituja vaatimuksia, mukaan lukien nämä vaaditut keskeiset vaatimukset:
iss
(Julkaisija): OpenID-palveluntarjoajan ainutlaatuinen tunniste, joka on antanut ID-tunnuksensub
(Kohde): Käyttäjän ainutlaatuinen tunnisteaud
(Yleisö): Asiakassovelluksen tunniste, joka vastaanottaa ID-tunnuksenexp
(Vanhentumisaika): Milloin ID-tunnus vanheneeiat
(Julkaisuaika): Milloin ID-tunnus on annettu
Yksityiskohtaisia tietoja ID-tunnuksista löytyy: ID-tunnus.
Käyttäjätietopäätepiste
Käyttäjätietopäätepiste on standardoitu HTTP API, jonka OP tarjoaa autentikoitujen käyttäjätietojen hankkimiseksi. Lähettämällä GET- tai POST-pyyntöjä pääsytunnuksella tähän päätepisteeseen, voit vastaanottaa käyttäjätietoja JSON-muodossa. Palautetut tiedot sisältävät standardoituja kenttiä, kuten yksilöllinen käyttäjä ID (sub), käyttäjänimi (name), sähköposti ja kuva.
Käyttäjätietojen hankkimisprosessi noudattaa samaa kaavaa kuin suojattujen resurssien käyttö OAuth 2.0:ssa. Yleensä käyttäjätiedot, jotka saadaan käyttäjätietopäätepisteestä, ovat kattavampia kuin ID-tunnuksessa olevat, sillä ID-tunnus palvelee ensisijaisesti identiteetin autentikointiin ja peruskäyttäjätietoihin.
Yksityiskohtaisia tietoja käyttäjätietopäätepisteestä löytyy: Käyttäjätietopäätepiste.
Huomaa, että käyttäjätiedot, joita saat käyttäjätietopäätepisteestä, riippuvat pyydetyistä rajauksista ja valtuutuksen aikana annetuista oikeuksista.
Rajaukset OIDC:ssa
Rajaukset OIDC:ssa määrittävät, mitä käyttäjätietoja RP voi käyttää. OIDC määrittelee standardoidut rajaukset, joista openid
-rajaus on pakollinen OIDC:n autentikointiprosesseissa.
Yleisiä standardoituja rajauksia ovat:
openid
: Ilmaisee OIDC-autentikointipyynnönprofile
: Peruskäyttäjätietoja kuten nimi ja avataremail
: Käyttäjän sähköpostitiedotphone
: Käyttäjän puhelinnumeroaddress
: Käyttäjän osoitetiedot
Eri rajaukset palauttavat erilaisia käyttäjätietoja. Esimerkiksi pyytämällä openid profile email
palautetaan peruskäyttäjätietoja ja sähköposti ID-tunnuksessa ja käyttäjätiedot, kun taas openid profile email phone address
sisältää myös puhelinnumeron ja osoitetiedot.
Identiteettien hallinta OIDC:n perusteella
OIDC ei ole pelkästään autentikointiprotokolla; se on tehokas työkalu joustavien, skaalautuvien identiteetinhallintajärjestelmien rakentamiseen. Lisäämällä autentikointikerros OAuth 2.0:aan, standardoimalla käyttäjätietoresurssit ja luomalla perustan laajennetuille identiteetinhallintatoiminnoille, OIDC mahdollistaa erilaisia identiteetinhallintaskenaarioita:
- Single Sign-On (SSO): OIDC tukee luonnostaan SSO:ta laajennettujen käyttäjäistuntojen tietojen kautta, mahdollistaen yhtenäisen kirjautumistilan hallinnan ja sovellusten välisen identiteetin jakamisen
- Organisaatiorakenteiden hallinta: Laajennetut käyttäjäorganisaatiotiedot voivat hallita monimutkaisia organisaatiorakenteita, mukaan lukien osastohierarkiat ja käyttäjäryhmäsuhteet
- Oikeuksien hallinta: Laajennetut käyttäjän oikeusattribuutit mahdollistavat hienojakoisen resurssien käyttöoikeuksien hallinnan, mukaan lukien roolitiedot ja oikeuspolitiikan konfigurointi
OIDC:n joustavuus mukautuu kehittyviin identiteetinhallinnan tarpeisiin. Monet identiteetinhallintajärjestelmät perustuvat OIDC:een, kuten Logto, joka tarjoaa SSO:n, organisaation hallinnan ja oikeuksien hallinnan toimintoja.