• oidc
  • openid connect
  • oauth
  • autentikointi
  • valtuutus

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.

Yijun
Yijun
Developer

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-tunnuksen
  • sub (Kohde): Käyttäjän ainutlaatuinen tunniste
  • aud (Yleisö): Asiakassovelluksen tunniste, joka vastaanottaa ID-tunnuksen
  • exp (Vanhentumisaika): Milloin ID-tunnus vanhenee
  • iat (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ön
  • profile: Peruskäyttäjätietoja kuten nimi ja avatar
  • email: Käyttäjän sähköpostitiedot
  • phone: Käyttäjän puhelinnumero
  • address: 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.