Suojatut pilvipohjaiset sovellukset OAuth 2.0:n ja OpenID Connectin avulla

Johdanto#

Pilvipohjaiset sovellukset ovat nykyään trendi. Vaikka sovellustyyppi vaihtelee (web, mobiili, desktop jne.), niillä kaikilla on pilvipalvelin, joka tarjoaa palveluita kuten tallennusta, laskentaa ja tietokantoja. Useimmiten nämä sovellukset tarvitsevat käyttäjien tunnistautumista ja valtuutusta pääsemään tiettyihin resursseihin.

Vaikka omatekoiset tunnistautumistavat ovat mahdollisia, turvallisuus on noussut yhdeksi suurimmista huolenaiheista kehittäessä pilvisovelluksia. Onneksi alallamme on testattuja standardeja kuten OAuth 2.0 ja OpenID Connect, jotka auttavat meitä toteuttamaan turvallista tunnistautumista ja valtuutusta.

Tämä julkaisu sisältää seuraavat oletukset:

1. Sinulla on perustiedot sovelluskehityksestä (web, mobiili tai muu tyyppi).
2. Olet kuullut tunnistautumisen ja valtuutuksen käsitteistä.
3. Olet kuullut OAuth 2.0:sta ja OpenID Connectistä.

Kyllä, "kuullut" riittää sekä kohtiin 2 että 3. Tämä julkaisu käyttää tosielämän esimerkkejä käsitteiden selittämiseen ja prosessin havainnollistamiseen kaavioin. Aloitetaan!

OAuth 2.0 vs. OpenID Connect#

Jos olet jo tuttu OAuth 2.0:n ja OpenID Connectin kanssa, voit jatkaa lukemista, koska käsittelemme tässä osiossa joitain tosielämän esimerkkejä; jos nämä standardit ovat sinulle uusia, on myös turvallista jatkaa, sillä esittelemme ne yksinkertaisella tavalla.

OAuth 2.0#

OAuth 2.0 on valtuutuskehys, jonka avulla sovellus voi saada rajoitetun pääsyn suojattuihin resursseihin toisessa sovelluksessa käyttäjän tai sovelluksen itsensä puolesta. Useimmat suositut palvelut kuten Google, Facebook ja GitHub käyttävät OAuth 2.0:aa esimerkiksi sosiaaliseen kirjautumiseen (esim. "Kirjaudu sisään Googlella").

Esimerkiksi, sinulla on web-sovellus MyApp, joka haluaa päästä käyttäjän Google Driveen. Sen sijaan että pyytäisit käyttäjää jakamaan Google Driven tunnuksensa, MyApp voi käyttää OAuth 2.0:aa pyytääkseen pääsyä Google Driveen käyttäjän puolesta. Tässä on yksinkertaistettu kaavio:

Tässä kaaviossa MyApp ei koskaan näe käyttäjän Google Driven tunnuksia. Sen sijaan se saa pääsytunnuksen Googlelta, jonka ansiosta se pääsee Google Driveen käyttäjän puolesta.

OAuth 2.0 -termein sanottuna, MyApp on asiakas, Google toimii sekä autorisointipalvelimena että resurssipalvelimena yksinkertaistuksen vuoksi. Todellisuudessa meillä on usein erillisiä autorisointi- ja resurssipalvelimia tarjotaksemme kertakirjautumiskokemuksen (SSO). Esimerkiksi, Google on autorisointipalvelin, ja sillä voi olla useita resurssipalvelimia kuten Google Drive, Gmail ja YouTube.

Huomaa, että todellinen autorisointivirtaus on monimutkaisempi kuin tämä. OAuth 2.0:ssa on erilaisia myöntämistyyppejä, laajuuksia ja muita käsitteitä, jotka tulisi ottaa huomioon. Jätetään tämä nyt sivuun ja siirrytään OpenID Connectin pariin.

OpenID Connect (OIDC)#

OAuth 2.0 on erinomainen valtuuttamiseen, mutta huomaat ehkä, että sillä ei ole tapaa tunnistaa käyttäjää (eli tunnistautuminen). OpenID Connect on tunnistuskerros OAuth 2.0:n päällä, joka lisää tunnistautumiskapasiteetin.

Edellisessä esimerkissä MyAppin täytyy tietää kuka käyttäjä on ennen kuin se aloittaa valtuutusprosessin. Huomaa, että tässä on mukana kaksi käyttäjää: MyAppin käyttäjä ja Google Driven käyttäjä. Tässä tapauksessa MyAppin on tiedettävä sen oman sovelluksen käyttäjä.

Katsotaanpa suoraa esimerkkiä, jossa käyttäjät voivat kirjautua MyAppiin käyttäjätunnuksella ja salasanalla:

Koska tunnistamme oman sovelluksemme käyttäjän, yleensä ei ole tarvetta pyytää lupaa, kuten Google teki OAuth 2.0 -virtauksessa. Samalla tarvitsemme jotain, joka voi tunnistaa käyttäjän. OpenID Connect esittelee käsitteet kuten ID-token ja userinfo endpoint auttamaan meitä siinä.

Huomaat ehkä, että tunnistuspalvelun tarjoaja (IdP) on uusi itsenäinen osallistuja virtauksessa. Se on sama kuin autorisointipalvelin OAuth 2.0:ssa, mutta selkeyden parantamiseksi käytämme termiä IdP osoittamaan, että se vastaa käyttäjän tunnistautumisesta ja identiteetin hallinnasta.

Kun liiketoimintasi kasvaa, sinulla voi olla useita sovelluksia, jotka jakavat saman käyttäjätietokannan. Kuten OAuth 2.0, OpenID Connect mahdollistaa yhden autorisointipalvelimen, joka voi tunnistaa käyttäjät useille sovelluksille. Jos käyttäjä on jo kirjautunut yhteen sovellukseen, hänen ei tarvitse syöttää tunnuksiaan uudelleen, kun toinen sovellus ohjaa hänet IdP:lle. Virtaus voidaan suorittaa automaattisesti ilman käyttäjän toimia. Tämä tunnetaan kertakirjautumisena (SSO).

Tämä on jälleen yksinkertaistettu virtaus ja siellä on enemmän yksityiskohtia kulissien takana. Tällä hetkellä siirrytään seuraavaan osioon tietoähkyn välttämiseksi.

Sovellustyypit#

Edellisessä osiossa käytimme web-sovelluksia esimerkkeinä, vaikka maailma onkin monimuotoisempi. Tunnistuspalvelun tarjoajalle ei ole merkitystä, mitä ohjelmointikieltä, työkalua tai alustaa käytät. Käytännössä huomattava ero on, onko sovellus julkinen asiakas vai yksityinen (luotettu) asiakas:

• Julkinen asiakas: Asiakas, joka ei voi pitää tunnuksiaan luottamuksellisina, mikä tarkoittaa, että resurssin omistaja (käyttäjä) voi käyttää niitä. Esimerkiksi web-sovellus, joka toimii selaimessa (esim. yksisivuinen sovellus).
• Yksityinen asiakas: Asiakas, joka pystyy pitämään tunnuksensa luottamuksellisina paljastamatta niitä (resurssin omistajille) käyttäjille. Esimerkiksi web-sovellus, joka toimii palvelimella (esim. palvelinpuolen web-sovellus) tai API-palvelu.

Näin ajatellen katsotaan, kuinka OAuth 2.0 ja OpenID Connect voidaan käyttää eri sovellustyypeissä.

"Sovellus" ja "asiakas" voidaan käyttää keskenään tämän julkaisun kontekstissa.

Web-sovellukset, jotka toimivat palvelimella#

Sovellus toimii palvelimella ja palvelee HTML-sivuja käyttäjille. Monet suositut web-kehykset kuten Express.js, Django ja Ruby on Rails kuuluvat tähän kategoriaan; ja backend-frontend -kehykset kuten Next.js ja Nuxt.js ovat myös mukana. Näillä sovelluksilla on seuraavat ominaisuudet:

1. Koska palvelin sallii vain yksityisen pääsyn (julkisilla käyttäjillä ei ole mahdollisuutta nähdä palvelimen koodia tai tunnuksia), sitä pidetään yksityisenä asiakkaana.
2. Käyttäjän tunnistautumisvirtaus on sama kuin se, josta keskustelimme "OpenID Connect" -osiossa.
3. Sovellus voi käyttää tunnistuspalvelimen (eli OpenID Connect -toimittajan) antamaa ID-tokenia käyttäjän tunnistamiseen ja käyttäjäkohtaisen sisällön näyttämiseen.
4. Pitäkseen sovellus turvallisena, sovellus käyttää yleensä valtuutuskoodivirtauksia käyttäjän tunnistautumiseen ja tokenien hankkimiseen.

Samaan aikaan sovellus voi tarvita pääsyn muihin sisäisiin API-palveluihin mikroarkkitehtuurissa; tai se on monoliittinen sovellus, joka tarvitsee käyttöoikeuden hallinnan eri osille sovellusta. Käsittelemme tätä "Suojaa API:si" -osiossa.

Yksisivuiset sovellukset (SPAs)#

Sovellus toimii käyttäjän selaimessa ja kommuniko kokonaan palvelimen kanssa API:en kautta. React, Angular ja Vue.js ovat suosittuja kehyksiä yksisivuisten sovellusten rakentamiseen. Näillä sovelluksilla on seuraavat ominaisuudet:

1. Koska sovelluksen koodi on julkisesti nähtävissä, sitä pidetään julkisena asiakkaana.
2. Käyttäjän tunnistautumisvirtaus on sama kuin se, josta keskustelimme "OpenID Connect" -osiossa.
3. Sovellus voi käyttää tunnistuspalvelimen (eli OpenID Connect -toimittajan) antamaa ID-tokenia käyttäjän tunnistamiseen ja käyttäjäkohtaisen sisällön näyttämiseen.
4. Pitäkseen sovellus turvallisena, sovellus käyttää yleensä valtuutuskoodivirtauksia PKCE:n (Proof Key for Code Exchange) kanssa käyttäjän tunnistautumiseen ja tokenien hankkimiseen.

Yleensä yksisivuiset sovellukset tarvitsevat pääsyn muihin API-palveluihin tietojen hakemiseksi ja päivittämiseksi. Käsittelemme tätä "Suojaa API:si" -osiossa.

Mobiilisovellukset#

Sovellus toimii mobiililaitteella (iOS, Android jne.) ja kommuniko kokonaan palvelimen kanssa API:en kautta. Useimmissa tapauksissa näillä sovelluksilla on samat ominaisuudet kuin yksisivuisilla sovelluksilla.

Koneiden välinen (M2M) sovellukset#

Koneiden väliset sovellukset ovat asiakkaita, jotka toimivat palvelimella (koneella) ja kommunikoivat muiden palvelimien kanssa. Näillä sovelluksilla on seuraavat ominaisuudet:

1. Kuten web-sovellukset, jotka toimivat palvelimella, M2M-sovellukset ovat yksityisiä asiakkaita.
2. Sovellus ei ehkä tarvitse tunnistaa käyttäjää; sen sijaan sen on tunnistettava itsensä päästääkseen muihin palveluihin.
3. Sovellus voi käyttää tunnistuspalvelimen (eli OAuth 2.0 -toimittajan) antamaa pääsytunnusta päästäkseen muihin palveluihin.
4. Pitäkseen sovellus turvallisena, sovellus käyttää yleensä asiakkaan tunnistetietovirtausta hankkiakseen pääsytunnuksia.

Kun sovellus käyttää muita palveluita, sen on ehkä annettava pääsytunnus pyyntöpäänimekkeeseen. Käsittelemme tätä "Suojaa API:si" -osiossa.

Sovellukset, jotka toimivat IoT-laitteilla#

Sovellus toimii IoT-laitteella (esim. älykotilaitteet, wearables, jne.) ja kommunikoit kokonaan palvelimen kanssa API:en kautta. Näillä sovelluksilla on seuraavat ominaisuudet:

1. Riippuen laitteen kyvykkyydestä, se voi olla julkinen tai yksityinen asiakas.
2. Kokonaisvaltainen tunnistautumisvirtaus voi erota siitä, mitä käsittelimme "OpenID Connect" -osiossa laitteen kyvykkyydestä johtuen. Esimerkiksi jotkin laitteet eivät ehkä sisällä näyttöä, johon käyttäjät syöttävät tunnuksensa.
3. Jos laitteen ei tarvitse tunnistaa käyttäjää, sen ei tarvitse käyttää ID-tokeneita tai userinfo endpointteja; sen sijaan sitä voidaan käsitellä koneiden välisenä (M2M) sovelluksena.
4. Pitäkseen sovellus turvallisena, sovellus voi käyttää valtuutuskoodivirtauksia PKCE:n (Proof Key for Code Exchange) kanssa käyttäjän tunnistautumiseen ja tokenien hankkimiseen tai asiakkaan tunnistetietovirtausta hankkiakseen pääsytunnuksia.

Kun se kommunikoi palvelimen kanssa, laite saattaa joutua antamaan pääsytunnuksen pyynnön päässä. Käsittelemme tätä "Suojaa API:si" -osiossa.

Suojaa api-si#

OpenID Connectin avulla on mahdollista tunnistaa käyttäjä ja hakea käyttäjäkohtaisia tietoja ID-tokeneiden tai userinfo endpointtien kautta. Tätä prosessia kutsutaan autentikoinniksi. Mutta et luultavasti halua paljastaa kaikkia resurssejasi kaikille tunnistautuneille käyttäjille, esimerkiksi vain ylläpitäjät voivat päästä käyttäjähallintasivulle.

Tässä vaiheessa valtuutus tulee kuvaan. Muista, että OAuth 2.0 on valtuutuskehys ja OpenID Connect on identiteettikerros OAuth 2.0:n päällä; mikä tarkoittaa, että voit käyttää myös OAuth 2.0:ta, kun OpenID Connect on jo käytössä.

Palataanpa esimerkkiin, jota käytimme "OAuth 2.0" -osiossa: MyApp haluaa päästä käyttäjän Google Driveen. Ei ole käytännöllistä antaa MyAppin pääsy kaikkiin käyttäjän tiedostoihin Google Drivessa. Sen sijaan MyAppin pitäisi nimenomaisesti väittää, mihin se haluaa päästä (esim. vain lukuoikeus tiedostoihin tietyssä kansiossa). OAuth 2.0 -termein tämä tunnetaan scope -termeillä.

Saatat nähdä termin "lupa" käytettynä vaihtokelpoisesti "scope" -termin kanssa OAuth 2.0:n kontekstissa, sillä joskus "scope" on epäselvä ei-teknisille käyttäjille.

Kun käyttäjä myöntää pääsyn MyAppille, valtuutuspalvelin myöntää pääsytunnuksen pyydetyllä scopella. Pääsytunnus lähetetään sitten resurssipalvelimeen (Google Drive) käyttäjän tiedostojen käyttämiseksi.

Luontevasti voimme korvata Google Driven omilla API-palveluillamme. Esimerkiksi, MyApp tarvitsee päästä OrderServiceen hakeakseen käyttäjän tilauksen historian. Tällä kertaa, koska käyttäjän tunnistautuminen on jo tehty tunnistuspalvelimen kautta ja sekä MyApp että OrderService ovat hallinnassamme, voimme ohittaa käyttäjän pääsypyynnön; MyApp voi suoraan lähettää pyynnön OrderServicelle tunnistuspalvelimen myöntämällä pääsytunnuksella.

Pääsytunnus voi sisältää read:order scope, joka osoittaa, että käyttäjä voi lukea tilaushistorian.

Nyt, sanotaan että käyttäjä vahingossa syöttää ylläpitäjän sivun URL:n selaimeen. Koska käyttäjä ei ole ylläpitäjä, pääsytunnuksessa ei ole admin-scopea. OrderService hylkää pyynnön ja palauttaa virheilmoituksen.

Tässä tapauksessa OrderService saattaa palauttaa 403 Forbidden statuskoodin osoittaakseen, että käyttäjällä ei ole valtuutusta päästä ylläpitäjän sivulle.

Koneiden välisissä (M2M) sovelluksissa ei ole mukana käyttäjää prosessissa. Sovellukset voivat pyytää suoraan pääsytunnuksia tunnistuspalvelimelta ja käyttää niitä päästäkseen muihin palveluihin. Sama käsite pätee: pääsytunnus sisältää tarvittavat scopet resurssien käytön hallintaan.

Autorisointisuunnittelu#

Voimme nähdä kaksi tärkeää asiaa, jotka on otettava huomioon suunniteltaessa autorisointia API-palveluittesi suojaamiseksi:

1. Scopet: Määritä, mihin asiakas voi päästä. Scopet voivat olla hienorakeisia (esim. read:order, write:order) tai yleisempiä (esim. order) tarpeidesi mukaan.
2. Käyttöoikeuksien hallinta: Määritä, kuka voi saada tietyt scopet. Esimerkiksi vain ylläpitäjät voivat saada admin-scope.

Mitä käyttöoikeuksien hallintaan tulee, suosittuja lähestymistapoja ovat:

• Roolipohjainen käyttöoikeuksien hallinta (RBAC): Määritä käyttäjille rooleja ja määritä, mitkä roolit voivat käyttää mitkä resurssit. Esimerkiksi ylläpitäjärooli voi käyttää ylläpitäjän sivua.
• Attribuuttipohjainen käyttöoikeuksien hallinta (ABAC): Määritä käytännöt attribuuttien (esim. käyttäjän osasto, sijainti jne.) perusteella ja tee käyttöoikeuspäätöksiä näiden attribuuttien perusteella. Esimerkiksi, käyttäjä, joka kuuluu "Engineering"-osastoon, voi päästä engineering-sivulle.

On syytä mainita, että molemmille lähestymistavoille standarditapa tarkistaa käyttöoikeuksien hallinta on tarkistaa pääsytunnusten scopet, eikä rooleja tai attribuutteja. Roolit ja attribuutit voivat olla erittäin dynaamisia ja scopet ovat staattisempia, mikä helpottaa hallintaa.

Yksityiskohaisempaa tietoa käyttöoikeuksien hallinnasta, voit tutustua RBAC:iin ja ABAC:iin: käyttöoikeuspäätösmallit, jotka sinun pitäisi tuntea.

Pääsytunnukset#

Vaikka olemme maininneet termin "pääsytunnus" monta kertaa, emme ole keskustelleet, miten sellaisen saa. OAuth 2.0:ssa pääsytunnus myönnetään autorisointipalvelimen (tunnistuspalvelin) toimesta onnistuneen autorisointivirtausten jälkeen.

Tarkastellaanpa tarkemmin Google Drive -esimerkkiä ja oletetaan, että käytämme valtuutuskoodivirtausta:

Virtauksen tärkeät vaiheet pääsytunnuksen myöntämiseksi:

• Vaihe 2 (Ohjaus Googlen sivulle): MyApp ohjaa käyttäjän Googleen autorisointipyynnöllä. Yleensä tähän pyyntöön sisältyy seuraavat tiedot:
  • Mikä asiakas (MyApp) aloittaa pyynnön
  • Mitä scopet MyApp vaatii
  • Minne Googlen tulisi ohjata käyttäjä, kun autorisointi on valmis
• Vaihe 5 (Pyydä lupaa päästä Google Driveen): Google pyytää käyttäjältä lupaa myöntää pääsy MyAppille. Käyttäjä voi joko myöntää tai kieltää pääsyn. Tätä vaihetta kutsutaan suostumukseksi.
• Vaihe 7 (Ohjaus MyAppille autorisointitietojen kanssa): Tämä vaihe on uusi kaaviossa. Sen sijaan, että Google palauttaisi pääsytunnuksen suoraan, Google palauttaa kertakekä toimii palvelimella ja kommuniko viimeinen valtuutuskoodi MyAppille turvallisempaa vaihtoa varten. Tätä koodia käytetään pääsytunnuksen hankkimiseen.
• Vaihe 8 (Käytä valtuutuskoodia vaihtaaksesi pääsytunnukseen): Tämä on myös uusi vaihe. MyApp lähettää valtuutuskoodin Googlelle vaihtaakseen pääsytunnukseen. Identiteettipalvelun tarjoajana Google yhdistää pyynnön kontekstin ja päättää, myönnetäänkö pääsytunnus:
  • Asiakas (MyApp) on se, joka se väittää olevansa
  • Käyttäjä on myöntänyt pääsyn asiakkaalle
  • Käyttäjä on se, joka hän väittää olevansa
  • Käyttäjällä on tarvittavat scopet
  • Valtuutuskoodi on voimassa eikä vanhentunut

Edellinen esimerkki olettaa, että autorisointipalvelin (tunnistuspalvelin) ja resurssipalvelin ovat saman (Googlen) alla. Jos ne ovat erillisiä, otetaan esimerkki MyAppista ja OrderServicesta, virtaus on seuraavanlainen:

Tässä virtauksessa autorisointipalvelin (IdP) myöntää sekä ID-tokenin että pääsytunnuksen MyAppille (vaihe 8). ID-tokenia käytetään käyttäjän tunnistamiseen, ja pääsytunnusta käytetään pääsemään muihin palveluihin kuten OrderServiceen. Koska sekä MyApp että OrderService ovat ensipuolen palveluita, yleensä ne eivät pyydä käyttäjältä pääsyn myöntämistä; pikemminkin ne luottavat tunnistuspalvelun pääsytunnuksiin päättääksesi, voiko käyttäjä käyttää resursseja (esim. sisältääkö pääsytunnus tarvittavat scopet).

Lopuksi katsotaan, miten pääsytunnusta käytetään koneiden välisissä (M2M) sovelluksissa. Koska prosessissa ei ole mukana käyttäjää ja sovellus on luotettu, se voi pyytää suoraan pääsytunnusta tunnistuspalvelimelta:

Käyttöoikeuksien hallinta voidaan silti soveltaa tähän. OrderServicelle ei ole merkitystä, kuka käyttäjä on tai mikä sovellus pyytää dataa; se välittää vain pääsytunnuksesta ja sen sisältämistä scopeista.

Pääsytunnukset ovat yleensä koodattuja JSON Web Tokeneina (JWT). Oppiaksesi lisää JWT:stä, voit viitata Mikä on JSON Web Token (JWT)?.

Resurssi-indikaattorit#

OAuth 2.0 esittelee käsitteen scopens käytön valvontaan. Kuitenkin saatat nopeasti huomata, että scopet eivät riitä:

• OpenID Connect määrittää sarjan standardiscopea kuten openid, offline_access ja profile. Saattaa olla hämmentävää sekoittaa nämä standardiscopeet omiin scopesiisi.
• Sinulla saattaa olla useita API-palveluita, jotka jakavat saman scopenimen, mutta niillä on eri merkitykset.

Yleinen ratkaisu on lisätä suffikseja (tai prefiksejä) scopen ja resurssin (API-palvelun) nimeämiseen. Esimerkiksi read:order ja read:product ovat selkeämpiä kuin read ja read. OAuth 2.0 -laajennus RFC 8707 esittelee uuden parametrin resource osoittamaan resurssipalvelin, johon asiakas haluaa päästä.

Todellisuudessa API-palvelut määritellään yleensä URL-osoitteilla, joten on luontevampaa käyttää URL-osoitteita resurssi-indikaattoreina. Esimerkiksi OrderService API voidaan esittää seuraavasti:

Kuten huomaat, parametri tuo mukavuutta käyttää varsinaisia resurssi-URL-osoitteita autorisointipyynnöissä ja pääsytunnuksissa. On syytä mainita, että kaikki identiteettipalveluntarjoajat eivät välttämättä ole toteuttaneet RFC 8707:ää. Sinun tulee tarkistaa identiteettipalveluntarjoajasi dokumentaatio nähdäksesi, tukeeko se resource-parametria (Logto tukee sitä).

Karkeasti sanottuna, resource-parametria voidaan käyttää autorisointipyynnöissä ja pääsytunnuksissa osoittamaan resurssia, johon asiakas haluaa päästä.

Resurssi-indikaattorien saavutettavuudelle ei ole mitään rajoituksia, eli resurssi-indikaattorin ei tarvitse olla oikea URL, joka osoittaa API-palveluun. Näin ollen nimi "resurssi-indikaattori" heijastaa sen roolia autorisointiprosessissa. Voit käyttää virtuaalisia URL-osoitteita edustamaan resursseja, joita haluat suojata. Esimerkiksi, voit määritellä virtuaalisen URL:n https://api.example.com/admin monoliittisovelluksessa edustamaan resurssia, johon vain ylläpitäjät voivat päästä.

Yhdistä kaikki#

Tässä vaiheessa olemme käsitelleet OAuth 2.0:n ja OpenID Connectin perusasiat ja kuinka käyttää niitä eri sovellustyypeissä ja skenaarioissa. Vaikka olemme käsitelleet niitä erikseen, voit yhdistellä niitä liiketoimintavaatimustesi mukaan. Kokonaisarkkitehtuuri voi olla niin yksinkertainen kuin tämä:

Tai hieman monimutkaisempi:

Kun sovelluksesi kasvaa, huomaat, että identiteettipalveluntarjoaja (IdP) pelaa ratkaisevaa roolia arkkitehtuurissa; mutta se ei liity suoraan liiketoimintatavoitteisiisi. Vaikka onkin loistava idea siirtää se luotettavalle toimittajalle, meidän on valittava identiteettipalveluntarjoaja viisaasti. Hyvä identiteettipalveluntarjoaja voi suuresti yksinkertaistaa prosessia, vähentää kehitystyön määrää ja pelastaa sinut mahdollisilta turvallisuusaukkoilta.

Lopetus#

Moderneille pilvisovelluksille identiteettipalveluntarjoaja (tai autorisointipalvelin) on keskeinen paikka käyttäjän autentikoinnille, identiteetinhallinnalle ja käyttöoikeuksien hallinnalle. Vaikka keskustelimme monista käsitteistä tässä julkaisussa, on vielä monia vivahteita, jotka on otettava huomioon toteutettaessa tällaista järjestelmää. Jos olet kiinnostunut oppimaan lisää, voit selata blogiamme saadaksesi syvällisempiä artikkeleita.