Ymmärrä IAM, OAuth, OpenID Connect, SAML, SSO ja JWT yhdessä artikkelissa

Identiteetin ja pääsynhallinnan (IAM) alue on kehittynyt monimutkaisemmaksi viime vuosien aikana. Hienot termit kuten OAuth, OpenID Connect (OIDC), SAML, SSO ja JWT ovat usein käytössä, mutta mitä ne tarkoittavat? Miten ne toimivat yhdessä? Tutkitaan näitä käsitteitä ja kehyksiä, jotta ne olisivat helpommin ymmärrettäviä ja käytännöllisiä.

Mitä IAM on?#

Identiteetin ja pääsynhallinta (IAM) on laaja käsite, joka käsittää digitaalisten identiteettien hallinnan ja pääsynhallinnan toteuttamisen. Aiemmin mainitut kehykset ja protokollat kuuluvat IAM:iin, ja kukin niistä käsittelee erityisiä haasteita tällä alueella.

Ytimessä IAM tarkoittaa:

• Identiteetti: Käyttäjän, palvelun tai laitteen digitaalinen esitys. Identiteetti sisältää yleensä ominaisuuksia kuten nimen, sähköpostin, roolit jne. kuvaamaan entiteettiä.
• Pääsy: Kyky vuorovaikuttaa resurssien kanssa, suorittaa toimintoja tai käyttää palveluita. Pääsy määrittelee, mitä toimia voidaan suorittaa missä resursseissa.

Yllä olevassa kaaviossa käyttäjä (identiteetti) haluaa suorittaa GET-pyynnön API:ssa (resurssi). Käyttäjän ominaisuudet - nimi, sähköposti ja rooli - kuvaavat identiteettiä.

Todennus vs. valtuutus#

Todennus ja valtuutus esiintyvät usein yhdessä IAM-keskusteluissa. Selvennetään niiden määritelmät:

• Todennus: Prosessi, jossa vahvistetaan identiteetin omistajuus. Se vastaa kysymykseen, "Mikä identiteetti sinulla on?"
• Valtuutus: Prosessi, jossa määritetään, mitä toimia todennettu identiteetti voi suorittaa resurssilla. Se vastaa kysymykseen, "Mitä voit tehdä?"

Aikaisemmassa esimerkissä:

• Ennen kuin käyttäjä (identiteetti) voi suorittaa mitään toimia, hänen on suoritettava todennusprosessi.
• Todennuksen jälkeen järjestelmän on määritettävä, voiko käyttäjä suorittaa GET-pyynnön (toiminta) API:ssa (resurssi), eli suoritettava valtuutusprosessi.

---

Tämän perustiedon varustamana, pureudutaan muihin lyhenteisiin ja protokolliin.

OAuth#

OAuth 2.0, jota usein kutsutaan OAuthiksi, on valtuutuskehys, joka mahdollistaa sovelluksen pääsyn suojattuihin resursseihin toisessa sovelluksessa (tyypillisesti käyttäjän puolesta).

Esimerkiksi, kuvittele, että sinulla on verkkosovellus nimeltä MyApp, joka haluaa päästä käsiksi käyttäjän Google Driveen. Sen sijaan, että pyytäisit käyttäjää jakamaan Google Driven kirjautumistietoja, MyApp voi käyttää OAuth 2.0:aa pyytääkseen lupaa (valtuutus) Googlen kautta päästäkseen käyttäjän Driveen.

Tässä on yksinkertaistettu kaavio, joka havainnollistaa OAuthin kulkua:

Tässä kulussa:

• MyApp on asiakas (identiteetti), joka pyytää pääsyä Google Driveen (resurssi).
• Käyttäjä (resurssin omistaja) antaa MyApp-sovellukselle luvan kohdassa 6, mikä täydentää valtuutusprosessin.

Keskeinen elementti OAuth 2.0:ssa on pääsytunnus, jota asiakas käyttää osoittamaan käyttäjän valtuutuksen päästä resursseihin. Tutustu tarkemmin, katso Pääsytunnus.

OpenID Connect (OIDC)#

OpenID Connect (OIDC) on todennuskerros, joka on rakennettu OAuth 2.0:n päälle. Se lisää erityisesti todennukseen liittyviä ominaisuuksia, kuten ID-tunnuksia ja UserInfo-päätepisteen, mikä tekee siitä soveltuvan sekä todennukseen että valtuutukseen.

Jos palaamme OAuth-kulkuihin, OIDC:n lisääminen tuo mukanaan ID-tunnuksen. Tämä tunnus sisältää tietoa todennetusta käyttäjästä ja mahdollistaa MyAppin varmistaa käyttäjän identiteetin.

Esimerkkitilanne: "Kirjaudu sisään Googlella"#

Vaihdetaan esimerkkiä. Jos MyApp haluaa sallia käyttäjien kirjautua sisään Google-tilejään käyttäen, tavoite vaihtuu todennukseen pikemminkin kuin resurssipääsyyn. Tässä tapauksessa OIDC sopii paremmin. Tässä on OIDC-kulku:

Keskeinen ero: Pääsytunnuksen lisäksi OIDC tarjoaa ID-tunnuksen, joka mahdollistaa MyAppin todentaa käyttäjän ilman lisäpäästöjä.

OIDC jakaa OAuth 2.0:n valtuutusmyönnöt varmistaen yhteensopivuuden ja johdonmukaisuuden kehysten välillä.

SAML#

Security Assertion Markup Language (SAML) on XML-pohjainen kehys todennus- ja valtuutustietojen vaihtamiseksi osapuolten välillä. SAML, joka otettiin käyttöön 2000-luvun alussa, on laajasti omaksuttu yritysympäristöissä.

Miten SAML vertautuu OIDC:hen?#

SAML ja OIDC ovat toiminnallisesti samanlaisia, mutta niiden toteutustavat eroavat toisistaan:

• SAML: Käyttää XML-pohjaisia ilmoituksia ja sitä pidetään usein monimutkaisempana.
• OIDC: Hyödyntää JSONia ja JWT:tä, mikä tekee siitä kevyemmän ja kehittäjäystävällisemmän.

Modernit sovellukset suosivat usein OIDC:tä sen yksinkertaisuuden ja joustavuuden vuoksi, mutta SAML on edelleen yleinen perinnesysteemeissä ja yrityskäytöissä.

Kertakirjautuminen (SSO)#

Kertakirjautuminen (SSO) on todennusjärjestelmä, joka mahdollistaa käyttäjien pääsyn useisiin sovelluksiin ja palveluihin yhdellä kirjautumistunnuksella. Sen sijaan, että kirjautuisi kunkin sovelluksen erikseen, käyttäjä kirjautuu kerran ja saa pääsyn kaikkiin liitettyihin järjestelmiin.

Miten SSO toimii?#

SSO luottaa keskitettyyn identiteettitoimittajaan (IdP) käyttäjien identiteettien hallinnassa. IdP todentaa käyttäjän ja tarjoaa palveluja, kuten todennuksen ja valtuutuksen liitetyille sovelluksille.

IdP voi käyttää protokollia, kuten OIDC:tä, OAuth 2.0:aa, SAML:ia tai muita tarjotakseen näitä palveluja. Yksi IdP voi tukea useita protokollia vastatakseen eri sovellusten monimutkaisiin tarpeisiin.

OIDC-Pohjaisen SSO:n Esimerkki#

Tutkitaan esimerkki OIDC-pohjaisesta SSO:sta:

Tässä kulussa käyttäjä kirjautuu IdP:hen kerran ja todennetaan useissa sovelluksissa (AppA ja AppB).

Yritys SSO#

Vaikka SSO on laaja käsite, saatat törmätä myös termiin yritys SSO, joka viittaa tietyn tyyppiseen SSO:hon, joka on suunniteltu yritysympäristöihin (tyypillisesti työntekijöille ja kumppaneille).

Kun asiakas pyytää SSO:ta sovelluksellesi, on tärkeää selvittää heidän tarpeensa ja käytössä olevat protokollat. Useimmissa tapauksissa tämä tarkoittaa, että tiettyjä sähköpostidomaineja varten he haluavat, että sovelluksesi ohjaa käyttäjät heidän IdP:hen (joka toteuttaa yritys SSO:n) todennustusta varten.

Esimerkki: Enterprise SSO -toimittajan lisääminen#

Tässä on yksinkertaistettu esimerkki Enterprise SSO -toimittajan (Banana) integroimisesta sovelluksesi (MyApp) kanssa:

JWT#

JSON Web Token (JWT) on avoin standardi, joka on määritelty RFC 7519:ssä ja joka mahdollistaa turvallisen viestinnän kahden osapuolen välillä. Se on standardiformaatti ID-tunnuksille OIDC:ssä ja sitä käytetään laajalti OAuth 2.0:n pääsytunnuksille.

Tässä ovat JWT:n keskeiset ominaisuudet:

• Kompakti: JWT:t ovat JSON-objekteja, jotka on koodattu kompaktiin muotoon, mikä tekee niistä helppoja siirtää ja tallentaa.
• Omavarainen: JWT:t sisältävät kaikki tarvittavat tiedot käyttäjästä ja itse tunnuksesta.
• Varmennettavissa ja kryptattavissa: JWT:t voidaan allekirjoittaa ja salata tietojen eheydestä ja luottamuksellisuudesta huolehtimiseksi.

Tyypillinen JWT näyttää tältä:

Tämä JWT koostuu kolmesta osasta, jotka on erotettu pisteillä:

• Header: Sisältää metatietoja tunnuksesta, kuten tunnuksen tyyppi ja allekirjoitusalgoritmi.
• Payload: Sisältää tietoa identiteetistä ja itse tunnuksesta.
• Signature: Varmistaa tunnuksen eheyden.

Sekä header että payload ovat base64-koodattuja JSON-objekteja. Yllä oleva JWT voidaan dekoodata seuraavasti:

JWT:n avulla asiakas voi dekoodata tunnuksen ja poimia käyttäjän tiedot ilman lisäkyselyitä identiteettitoimittajalle. Lisätietoja JWT:stä saat JSON Web Token (JWT).

Yhteenveto#

Olemme kattaneet paljon tietoa tässä artikkelissa. Tehdään yhteenveto tärkeimmistä kohdista esimerkin avulla:

Kuvittele, että sinulla on verkkosovellus, AppA, joka tarvitsee identiteetin ja pääsynhallinnan (IAM) ratkaisun. Valitset Logto-nimisen identiteettitoimittajan, joka käyttää OpenID Connectiä (OIDC) todennukseen. Koska OIDC perustuu OAuth 2.0:aan, Logto tukee myös valtuutusta sovelluksellesi.

Vähentääksesi kitkaa käyttäjillesi, otat Logtossa käyttöön "Kirjaudu sisään Googlella". Tämä käyttää OAuth 2.0:aa vaihtaakseen valtuutustietoja ja käyttäjätietoja Logton ja Googlen välillä.

Kun käyttäjä kirjautuu AppA:han Logton kautta, AppA saa ID-tunnuksen, joka on JSON Web Token (JWT), joka sisältää käyttäjän tiedot.

Kun liiketoimintasi kasvaa, lanseeraat uuden sovelluksen, AppB, joka tarvitsee myös käyttäjän todennuksen. Koska Logto on jo asennettu, voit käyttää samaa todennusprosessia AppB:lle. Käyttäjäsi voivat nyt kirjautua sekä AppA:han että AppB:hen yhdellä kirjautumistunnuksella, joka tunnetaan nimellä kertakirjautuminen (SSO).

Myöhemmin liikekumppani pyytää sinua yhdistämään heidän yritys SSO-järjestelmänsä, joka käyttää Security Assertion Markup Language (SAML):ia. Huomaat, että Logto tukee SAML-yhteyksiä, joten asetat yhteyden Logton ja kumppanin SSO-järjestelmän välillä. Näin käyttäjät kumppaniorganisaatiosta voivat myös kirjautua AppA:han ja AppB:hen olemassa olevilla kirjautumistiedoillaan.

---

Toivon, että tämä artikkeli on selventänyt nämä käsitteet sinulle. Yksityiskohtaisempia selityksiä ja esimerkkejä varten tutustu Auth Wiki -sivustoon. Jos etsit IAM-ratkaisua sovelluksellesi, harkitse hallitun palvelun, kuten Logto, käyttöä säästääksesi aikaa ja vaivaa.