Huomautus. käännös: Tämä hieno Oktan artikkeli selittää, kuinka OAuth ja OIDC (OpenID Connect) toimivat yksinkertaisesti ja selkeästi. Tämä tieto on hyödyllistä kehittäjille, järjestelmänvalvojille ja jopa suosittujen verkkosovellusten "tavallisille käyttäjille", jotka todennäköisesti myös vaihtavat luottamuksellisia tietoja muiden palvelujen kanssa.
Internetin kivikaudella tiedon jakaminen palveluiden välillä oli helppoa. Annoit vain käyttäjätunnuksesi ja salasanasi palvelusta toiseen, jotta hän tuli tilillesi ja sai kaikki tarvitsemansa tiedot.
"Anna minulle pankkitilisi." ”Lupaan, että salasanan ja rahan kanssa kaikki on hyvin. Se on rehellistä, rehellistä!" *hee hee*
Kauhu! Kenenkään ei pitäisi koskaan vaatia käyttäjää jakamaan käyttäjätunnusta ja salasanaa, valtakirjat, toisella palvelulla. Ei ole takeita siitä, että tämän palvelun takana oleva organisaatio pitää tiedot turvassa eikä kerää enempää henkilökohtaisia tietoja kuin on tarpeen. Se saattaa kuulostaa hullulta, mutta jotkut sovellukset käyttävät edelleen tätä käytäntöä!
Nykyään on olemassa yksi standardi, jonka avulla yksi palvelu voi käyttää turvallisesti toisen tietoja. Valitettavasti tällaisissa standardeissa käytetään paljon ammattikieltä ja termejä, mikä vaikeuttaa niiden ymmärtämistä. Tämän materiaalin tarkoituksena on selittää, kuinka ne toimivat yksinkertaisten kuvien avulla (Luuletko, että piirustukseni muistuttavat lasten värjäystä? Ai niin!).
Tämä opas on muuten saatavilla myös videomuodossa:
Hyvät naiset ja herrat, tervetuloa: OAuth 2.0
on suojausstandardi, jonka avulla yksi sovellus voi saada luvan käyttää toisen sovelluksen tietoja. Luvan myöntämisen vaiheet [lupa] (tai suostumus [suostumus]) soittaa usein valtuutus [valtuutus] tai delegoitu valtuutus [valtuutettu valtuutus]. Tämän standardin avulla annat sovelluksen lukea tietoja tai käyttää toisen sovelluksen toimintoja puolestasi antamatta sille salasanaasi. Luokka!
Oletetaan esimerkiksi, että löydät sivuston nimeltä "Päivän epäonninen sana". [Päivän kauhea sana] ja päätti rekisteröityä siihen saadakseen päivittäisiä sanaleikkejä puhelimeen tekstiviestien muodossa. Pidin todella sivustosta ja päätit jakaa sen kaikkien ystäviesi kanssa. Loppujen lopuksi kaikki pitävät kammottavasta sanaleikasta, eikö niin?
”Päivän valitettava sanapeli: Oletko kuullut miehestä, joka menetti vasemman puoliskon kehostaan? Nyt hän on aina oikeassa!" (likimääräinen käännös, koska alkuperäisellä on oma sanapeli - n. käännös.)
On selvää, että jokaiselle yhteystietoluettelon henkilölle kirjoittaminen ei ole vaihtoehto. Ja jos olet edes vähän kuin minä, teet kaikkesi välttääksesi turhaa työtä. Onneksi Terrible Pun of the Day voi kutsua kaikki ystäväsi yksin! Tätä varten sinun tarvitsee vain avata yhteystietojesi sähköpostit - sivusto itse lähettää heille kutsut (OAuth-säännöt)!
"Kaikki rakastavat sanaleikkejä! - Jo kirjautunut sisään? "Haluatko antaa Terrible Pun of the Day -sivuston käyttää yhteystietoluetteloasi? - Kiitos! Tästä eteenpäin lähetämme muistutuksia joka päivä kaikille tutuille, aikojen loppuun asti! Olet paras ystävä!"
- Valitse sähköpostipalvelusi.
- Siirry tarvittaessa sähköpostisivustolle ja kirjaudu sisään tilillesi.
- Anna The Terrible Pun of the Day -käyttöoikeus yhteystietoihisi.
- Palaa The Terrible Pun of the Day -sivustolle.
Jos muutat mielesi, OAuthia käyttävät sovellukset tarjoavat myös tavan peruuttaa käyttöoikeudet. Kun päätät, ettet enää halua jakaa yhteystietoja Terrible Pun of the Dayn kanssa, voit siirtyä sähköpostisivustolle ja poistaa sanapelisivuston valtuutettujen sovellusten luettelosta.
OAuth Flow
Olemme juuri käyneet läpi sen, mitä yleensä kutsutaan virtaus [virtaus] OAuth. Esimerkissämme tämä vuo koostuu näkyvistä vaiheista sekä useista näkymättömistä vaiheista, joissa kaksi palvelua sopivat turvallisesta tiedonvaihdosta. Edellinen Terrible Pun of the Day -esimerkki käyttää yleisintä OAuth 2.0 -kulkua, joka tunnetaan nimellä "valtuutuskoodi". ["valtuutuskoodi"-kulku].
Ennen kuin sukeltaa OAuthin toiminnan yksityiskohtiin, puhutaanpa joidenkin termien merkityksestä:
- Resurssin omistaja:
Se olet sinä! Omistat kirjautumistietosi, tietosi ja hallitset kaikkia tileilläsi mahdollisesti suoritettavia toimintoja. - Asiakas:
Sovellus (esimerkiksi The Terrible Pun of the Day -palvelu), joka haluaa käyttää tai suorittaa tiettyjä toimintoja Resurssin omistaja'а. - Valtuutuspalvelin:
Sovellus, joka tietää Resurssin omistaja'a ja jossa u Resurssin omistaja'on jo tili. - resurssipalvelin:
Sovellusohjelmointirajapinta (API) tai palvelu, joka Asiakas haluaa käyttää puolesta Resurssin omistaja'а. - Uudelleenohjaus URI:
Tuo linkki Valtuutuspalvelin ohjaa uudelleen Resurssin omistaja'ja luvan myöntämisen jälkeen Asiakas'at. Sitä kutsutaan joskus "takaisinkutsun URL-osoitteeksi". - Vastaustyyppi:
Odotettavissa olevan tiedon tyyppi Asiakas. Yleisin Vastaustyyppi'ohm on koodi, eli Asiakas odottaa saavansa Valtuutuskoodi. - Laajuus:
Tämä on yksityiskohtainen kuvaus tarvittavista käyttöoikeuksista Asiakas'y, kuten tietojen käyttö tai tiettyjen toimintojen suorittaminen. - Suostumus:
Valtuutuspalvelin baskeri Kaukoputketpyydetty Asiakas'om, ja kysyy Resurssin omistaja'a, onko hän valmis tarjoamaan Asiakas'on tarvittavat käyttöoikeudet. - Asiakastunnus:
Tätä tunnusta käytetään tunnistamiseen Asiakas'a päällä Valtuutuspalvelin'e. - Asiakassalaisuus:
Tämä on vain tiedossa oleva salasana Asiakas'sinä ja Valtuutuspalvelin'at. Sen avulla he voivat jakaa tietoja yksityisesti. - Valtuutuskoodi:
Väliaikainen koodi, jolla on lyhyt voimassaoloaika Asiakas tarjoaa Valtuutuspalvelin'y vastineeksi Käyttöoikeustunnus. - Käyttöoikeustunnus:
Avain, jonka kanssa asiakas kommunikoi resurssipalvelin'om. Eräänlainen merkki tai avainkortti, joka tarjoaa Asiakas"heillä on lupa pyytää tietoja tai suorittaa toimintoja resurssipalvelinsinun puolestasi.
Huomata: Joskus valtuutuspalvelin ja resurssipalvelin ovat sama palvelin. Joissakin tapauksissa nämä voivat kuitenkin olla eri palvelimia, vaikka ne eivät kuuluisi samaan organisaatioon. Valtuutuspalvelin voi esimerkiksi olla kolmannen osapuolen palvelu, johon resurssipalvelin luottaa.
Nyt kun olemme käsitelleet OAuth 2.0:n ydinkäsitteet, palataanpa esimerkkiimme ja tarkastellaan tarkemmin, mitä OAuth-kulussa tapahtuu.
- Sinä, Resurssin omistaja, haluat tarjota kauhean päivän sanapalvelun (Asiakasy) pääsy yhteystietoihisi, jotta he voivat lähettää kutsuja kaikille ystävillesi.
- Asiakas ohjaa selaimen sivulle Valtuutuspalvelin'a ja sisällytä kyselyyn Asiakastunnus, Uudelleenohjaus URI, Vastaustyyppi ja yksi tai useampi Kaukoputket (luvat) se tarvitsee.
- Valtuutuspalvelin vahvistaa sinut ja pyytää tarvittaessa käyttäjätunnusta ja salasanaa.
- Valtuutuspalvelin näyttää lomakkeen Suostumus (vahvistukset) ja luettelo kaikista Kaukoputketpyydetty Asiakas'om. Olet samaa mieltä tai kieltäydyt.
- Valtuutuspalvelin ohjaa sinut sivustolle Asiakas'a, käyttämällä Uudelleenohjaus URI kanssa Valtuutuskoodi (valtuutuskoodi).
- Asiakas kommunikoi suoraan Valtuutuspalvelin'ohm (ohita selain Resurssin omistaja'a) ja lähettää turvallisesti Asiakastunnus, Asiakassalaisuus и Valtuutuskoodi.
- Valtuutuspalvelin tarkistaa tiedot ja vastaa Käyttöoikeustunnus'om (käyttöoikeus).
- Nyt Asiakas voi käyttää Käyttöoikeustunnus pyynnön lähettämiseen resurssipalvelin saadaksesi yhteystietoluettelon.
Asiakastunnus ja salaisuus
Kauan ennen kuin annoit Terrible Pun of the Dayn käyttää yhteystietojasi, asiakas ja valtuutuspalvelin olivat luoneet työsuhteen. Valtuutuspalvelin loi asiakastunnuksen ja asiakassalaisuuden (joita joskus kutsutaan App tunnus и Sovelluksen salaisuus) ja lähetti ne asiakkaalle OAuthin vuorovaikutusta varten.
"- Hei! Haluaisin työskennellä kanssasi! - Totta kai, ei ongelma! Tässä on asiakastunnuksesi ja salaisuutesi!”
Nimi viittaa siihen, että asiakassalaisuus on pidettävä salassa, jotta vain asiakas ja valtuutuspalvelin tietävät sen. Loppujen lopuksi valtuutuspalvelin vahvistaa asiakkaan totuuden hänen avullaan.
Mutta siinä ei vielä kaikki... Tervetuloa OpenID Connectiin!
OAuth 2.0 on suunniteltu vain valtuutus - tarjota pääsy tietoihin ja toimintoihin sovelluksesta toiseen. (OIDC) on ohut kerros OAuth 2.0:n päällä, joka lisää tilille kirjautuneen käyttäjän kirjautumis- ja profiilitiedot. Kirjautumisistunnon järjestämistä kutsutaan usein nimellä todennus [todennus]ja tiedot järjestelmään kirjautuneesta käyttäjästä (esim Resurssin omistaja'e), — henkilökohtaiset tiedot [identiteetti]. Jos valtuutuspalvelin tukee OIDC:tä, sitä kutsutaan joskus nimellä henkilötietojen tarjoaja [henkilöllisyyden tarjoaja]koska se tarjoaa Asiakas'on tietoa aiheesta Resurssin omistaja'e.
OpenID Connectin avulla voit toteuttaa skenaarioita, joissa yhtä kirjautumista voidaan käyttää useissa sovelluksissa - tämä lähestymistapa tunnetaan myös nimellä kertakirjautuminen (SSO). Sovellus voi esimerkiksi tukea SSO-integraatiota sosiaalisten verkostojen, kuten Facebookin tai Twitterin, kanssa, jolloin käyttäjät voivat käyttää tiliä, joka heillä on jo ja jota he haluavat käyttää.
OpenID Connect -kulku näyttää samalta kuin OAuthin tapauksessa. Ainoa ero on, että ensisijaisessa pyynnössä käytetään erityistä laajuutta openid, - A Asiakas lopulta tulee sellaiseksi KäyttöoikeustunnusJa ID Token.
Aivan kuten OAuth-virtauksessa, Käyttöoikeustunnus OpenID Connectissa tämä arvo on epäselvä Asiakas'at. Näkökulmasta Asiakas'а Käyttöoikeustunnus edustaa merkkijonoa, joka välitetään jokaisen pyynnön mukana resurssipalvelin'y, joka määrittää, onko tunnus kelvollinen. ID Token edustaa täysin eri asiaa.
ID Token on JWT
ID Token on erityisesti muotoiltu merkkijono, joka tunnetaan nimellä JSON Web Token tai JWT (joskus JWT-merkit lausutaan "jots"). Ulkopuolisille tarkkailijoille JWT saattaa tuntua käsittämättömältä hölynpölyltä, mutta Asiakas voi poimia JWT:stä erilaisia tietoja, kuten tunnuksen, käyttäjätunnuksen, sisäänkirjautumisajan, vanhenemispäivän ID Token'a, JWT:tä on yritetty häiritä. Tiedot sisällä ID Token'a kutsutaan sovellukset [väitteet].
OIDC:n tapauksessa on myös standardi tapa, jolla Asiakas voi pyytää lisätietoja henkilöstä [identiteetti] alkaen Valtuutuspalvelin'a esimerkiksi sähköpostiosoite, joka käyttää Käyttöoikeustunnus.
Lisätietoja OAuthista ja OIDC:stä
Joten tarkastelimme lyhyesti, kuinka OAuth ja OIDC toimivat. Oletko valmis kaivamaan syvemmälle? Tässä on lisäresursseja, joiden avulla saat lisätietoja OAuth 2.0:sta ja OpenID Connectista:
Kuten aina, kommentoi rohkeasti. Pysy ajan tasalla viimeisimmistä uutisistamme tilaamalla и Okta kehittäjille!
PS kääntäjältä
Lue myös blogistamme:
- «";
- «";
- «";
- «'.
Lähde: will.com