OAuth: kuvaus protokollasta yksinkertaisella ja ymmärrettävällä kielellä. Kuinka saada asiakastunnus ja salainen avain. Apurahan tyyppi: Asiakkaan tunnistetiedot

OAuth 2 on valtuutuskehys, joka mahdollistaa hakemusten vastaanottamisen rajoitettu pääsy käyttäjätileille kautta HTTP, kuten Facebook, GitHub Ja DigitalOcean. Se toimii delegoimalla käyttäjätunnuksen käyttäjätiliä isännöivälle palvelulle ja valtuuttamalla kolmannen osapuolen sovelluksia, joilla on pääsy tili käyttäjä. OAuth 2 tarjoaa valtuutuskulkuja pöytäkoneille, verkkosovelluksille ja mobiililaitteille.

Tämä tietoopas tarkoitettu sovellusten kehittäjille ja tarjoaa yleiskatsauksen rooleista OAuth 2, valtuutettujen käyttöoikeuksien tyypit, käytetyt tilanteet ja virrat.

Aloitetaan rooleista OAuth 2!

OAuth-roolit

Oauth määrittelee 4 roolia:

• Resurssin omistaja
• Asiakas
• Resurssipalvelin
• Valtuutuspalvelin

Erittelemme kunkin roolin seuraavissa alaosissa.

Resurssin omistaja: Käyttäjä

Resurssin omistaja on käyttäjä, joka käyttää sovellusta päästäkseen tilille. Sovelluksen pääsyä käyttäjän tilille rajoittaa valtuutusoikeuksien laajuus (esimerkiksi luku- tai kirjoitusoikeus).

Resurssi/valtuutuspalvelin: API

Resurssipalvelin tallentaa suojatut käyttäjätilit, ja valtuutuspalvelin vahvistaa käyttäjän henkilöllisyyden ja myöntää sitten sovellukselle käyttöoikeudet.

Sovelluskehittäjien näkökulmasta palvelun API suorittaa molemmat roolit sekä resurssipalvelimena että valtuutuspalvelimena. Ohjaamme molempiin yhdistettyihin rooleihin, sekä Palvelu- että API-rooliin.

Asiakas: Sovellus

Asiakas on sovellus, joka haluaa käyttää käyttäjän tiliä. Ennen kuin se voi tehdä tämän, käyttäjän on sallittava se ja API:n on vahvistettava valtuutus.

Nyt sinulla on käsitys OAuth-rooleista. Katsotaanpa kaaviota siitä, kuinka ne yleensä ovat vuorovaikutuksessa keskenään:

Tässä lisää yksityiskohtainen selitys vaiheet kaaviossa:

1. Sovellus pyytää käyttäjältä lupaa käyttää palveluresursseja
2. Jos käyttäjä on hyväksynyt pyynnön, sovellus saa valtuutuksen
3. Sovellus pyytää käyttöoikeustunnusta valtuutuspalvelimelta (palvelu API), joka todistaa sen aitoudesta ja myöntää valtuutuksen
4. Jos sovelluksen identiteetti on aito ja valtuutus on voimassa, valtuutuspalvelin (API) antaa sovellukselle käyttöoikeustunnuksen. Valtuutus on valmis.
5. Sovellus pyytää resurssia resurssipalvelimelta (API) ja tarjoaa pääsytunnuksen henkilöllisyytensä todistamiseksi
6. Jos käyttöoikeustunnus on kelvollinen, resurssipalvelin (API) välittää resurssin sovellukselle

Tämän prosessin todellinen kulku vaihtelee käytetyn valtuutuksen tyypin mukaan - tämä on yleinen ajatus. Me opiskellaan Erilaisia ​​tyyppejä tarjotaan seuraavassa osiossa.

Hakemuksen rekisteröinti

Ennen kuin käytät OAuthia sovelluksessasi, sinun on rekisteröitävä sovelluksesi palveluun. Tämä tehdään rekisteröintilomakkeella palvelun verkkosivuston Kehittäjä- tai API-osiossa, jossa annat seuraavat tiedot (ja todennäköisesti yksityiskohtainen tieto hakemuksestasi):

• sovelluksen nimi
• Sovellussivusto
• Uudelleenohjaa URI tai URL soita takaisin

URI-uudelleenohjausta käytetään silloin, kun palvelu ohjaa käyttäjän uudelleen sen jälkeen, kun sovelluksesi on valtuutettu tai evätty, eli se osa sovelluksesta, joka käsittelee valtuutuskoodeja tai käyttöoikeuksia.

Asiakastunnus ja salainen koodi asiakas

Kun hakemuksesi on rekisteröity, palvelu antaa "asiakastunnukset" asiakastunnuksen ja asiakassalaisuuden muodossa. Asiakastunniste on julkinen merkkijono, jota palvelun API käyttää sovelluksen tunnistamiseen ja jota käytetään myös käyttäjille esitettävien valtuutus-URL-osoitteiden luomiseen. Asiakassalaisuutta käytetään sovelluksen todentamiseen API-palveluun, kun sovellus pyytää pääsyä käyttäjän tilille, ja se on pidettävä salassa sovelluksen ja API:n välillä.

Valtuutuksen myöntäminen

SISÄÄN abstrakti protokollavirta Yllä neljä ensimmäistä vaihetta kuvaavat valtuutusluvan ja käyttöoikeustunnuksen hankkimista. Myönnetty valtuutustyyppi riippuu menetelmästä, jota sovellus käyttää valtuutuksen pyytämiseen, ja tuettujen API:iden myöntämistyypeistä. OAuth 2 määrittelee neljä lupatyyppiä, joista jokainen on hyödyllinen eri tilanteissa:

• Valtuutuskoodi: käytetään yhdessä palvelinpuolen sovellusten kanssa

• Implisiittisyys (piilollisuus): Käytetty mobiilisovelluksia tai verkkosovellukset (käyttäjän laitteessa toimivat sovellukset)

• : Käytetty luotettavia sovelluksia, kuten ne, jotka itse palvelu omistaa

• Asiakkaan tunnistetiedot: käytetään API-käyttösovellusten kanssa

Kuvaamme nyt seuraavissa osioissa yksityiskohtaisemmin säännöstyyppejä, niiden käyttötapauksia ja virtoja.

Apurahan tyyppi: Valtuutuskoodi

Valtuutuskoodin tarjontatyyppi on eniten käytetty, koska se on optimoitu palvelinpuolen sovelluksille, joissa lähde ei näytetä julkisesti ja asiakkaan salaisen koodin luottamuksellisuus voidaan säilyttää. Tämä on uudelleenohjauspohjainen kulku, mikä tarkoittaa, että sovelluksen on kyettävä olemaan vuorovaikutuksessa käyttäjäagentin (eli käyttäjän selaimen) kanssa ja vastaanottamaan API-valtuutuskoodeja, jotka reititetään käyttäjäagentin kautta.

Vaihe 1: Valtuutuskoodin linkki

• https://cloud.digitalocean.com/v1/oauth/authorize - API-valtuutuksen päätepiste
• vastaus_tyyppi=koodi - määrittää, että sovelluksesi pyytää valtuutuskoodia
• client_id=CLIENT_ID — sovelluksen asiakastunniste (arvo, jolla API tunnistaa sovelluksen)
• redirect_uri=CALLBACK_URL — paikka, johon palvelu uudelleenohjaa selaimen valtuutuskoodin antamisen jälkeen
• soveltamisala=read - määrittää sovelluksen pyytämän käyttöoikeustason

Kun käyttäjä napsauttaa linkkiä, hänen on ensin kirjauduttava palveluun vahvistaakseen henkilöllisyytensä (ellei hän ole jo kirjautunut sisään). Palvelu pyytää sitten heiltä vahvistusta salliakseen tai estääkseen sovelluksen pääsyn heidän tililleen. Tässä on esimerkki sovelluksesta, joka pyytää pääsyä tiliin:

Sovelluksen valtuutus

Lupien yleiskatsaus(käyttöoikeudet)

• Lukeminen

Valtuuta sovellus Kieltää

Jos käyttäjä napsauttaa "Valtuuta sovellus", palvelu ohjaa selaimen asiakkaan rekisteröinnin yhteydessä määritettyyn sovelluksen uudelleenohjaus-URI:hen valtuutuskoodin kanssa. Uudelleenohjaus näyttäisi tältä (olettaen, että sovelluksen osoite on "dropletbook.com"):

Vaihe 4: Sovellus saa käyttöoikeustunnuksen

Sovellus pyytää käyttöoikeustunnusta API:lta välittämällä valtuutuskoodin API-tunnuksen päätepisteeseen sekä yksityiskohtainen tieto tunnistamisesta, mukaan lukien asiakkaan salainen koodi. Tässä on esimerkkipyyntö POST:n kautta DigitalOcean-tunnuksen päätepisteeseen:

Vaihe 5: Sovellus saa käyttöoikeustunnuksen

("access_token":"ACCESS_TOKEN","tunnisteen_tyyppi":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN","scope":"read","uid":100101,"info":( "nimi":"Mark E. Mark","email":" [sähköposti suojattu] «}}

Sovellus on nyt hyväksytty! Se voi käyttää tunnusta päästäkseen käyttäjän tilille palvelun API:n kautta käyttörajoituksin, kunnes tunnus vanhenee tai se peruutetaan. Jos päivitystunnus on välitetty, sitä voidaan käyttää uusien käyttöoikeuksien pyytämiseen, jos alkuperäinen token on vanhentunut.

Apurahan tyyppi: Implisiittisyys (piilollisuus)

Implisiittistä tarjontatyyppiä käytetään mobiilisovelluksissa ja verkkosovelluksissa (eli sovelluksissa, jotka toimivat selaimessa), joissa asiakassalaisuuden luottamuksellisuutta ei taata. Implisiittinen lupatyyppi on myös uudelleenohjauspohjainen stream, mutta pääsytunnus annetaan selaimelle siirtyäkseen sovellukseen, jotta sekä käyttäjä että muut käyttäjän laitteen sovellukset voivat käyttää sitä. Lisäksi tämä kulku ei todenna sovelluksen identiteettiä ja käyttää tätä tarkoitusta varten uudelleenohjaus-URI:ta (joka on rekisteröity palveluun).

Implisiittinen lupatyyppi ei tue päivitystunnuksia.

Implisiittinen lupavirta toimii periaatteessa näin: käyttäjää pyydetään valtuuttamaan sovellus, jonka jälkeen valtuutuspalvelin välittää pääsytunnuksen takaisin selaimelle, joka puolestaan ​​välittää sen sovellukselle. Jos olet kiinnostunut yksityiskohdista, lue.

Implisiittisen lupatyypin kanssa käyttäjälle annetaan valtuutuslinkki, joka pyytää sovellusliittymältä tunnuksen. Tämä linkki näyttää valtuutuskoodilinkiltä, ​​paitsi että se pyytää koodia koodin sijaan (huomaa, että pyyntötyyppi on "token"):

Huomautus

Kun käyttäjä napsauttaa linkkiä, hänen on ensin kirjauduttava palveluun vahvistaakseen henkilöllisyytensä (jos hän ei ole jo kirjautunut sisään). Palvelu pyytää heitä sitten sallimaan tai estämään sovelluksen pääsyn tiliinsä. . Tässä on esimerkki sovelluksesta, joka pyytää pääsyä tiliin:

Sovelluksen valtuutus

Thedropletbook pyytää lupaa käyttää tiliäsi

Lupien yleiskatsaus(käyttöoikeudet)

• Lukeminen

Valtuuta sovellus Kieltää

Näemme, että "Thedropletbook App" pyytää lupaa lukea tiliä " [sähköposti suojattu] ”.

Vaihe 3: Selain vastaanottaa käyttöoikeustunnuksen, jossa on uudelleenohjaus-URI

Vaihe 4: Selain seuraa uudelleenohjaus-URI:tä

Selain seuraa uudelleenohjaus-URI:tä, mutta säilyttää pääsytunnuksen.

Vaihe 5: Sovellus lähettää käyttötunnuksen poimintakomentosarjaan

Sovellus palauttaa sivun, joka sisältää komentosarjan, joka voi poimia pääsytunnuksen koko selaimen tallentamasta uudelleenohjaus-URI:sta.

Vaihe 6: Käyttöoikeustunnus välitetään sovellukselle

Selain suorittaa toimitetun komentosarjan ja välittää haetun pääsytunnuksen sovellukselle.

Huomautus: DigitalOcean ei tue annettu aika implisiittinen lupatyyppi, jotta linkki osoittaa kuvitteelliseen valtuutuspalvelimeen osoitteessa "oauth.example.com".

Apurahan tyyppi: Tunnistetietojen salasanaresurssin omistaja

Valtuustietosalasanan resurssin omistajan myöntämistyypillä käyttäjä antaa palvelutunnistetietonsa (käyttäjätunnuksen ja salasanan) suoraan sovellukselle, joka käyttää valtuustietoja pääsytunnuksen hankkimiseen palvelusta. Tämä lupatyyppi tulee ottaa käyttöön valtuutuspalvelimessa vain, jos muut virtaukset eivät ole käyttökelpoisia. Sitä tulee käyttää myös, jos käyttäjä luottaa sovellukseen (esimerkiksi jos se kuuluu palveluun tai käyttöjärjestelmä tietokone).

Tunnistetietojen salasanavirta

Kun käyttäjä on antanut tunnistetietonsa sovellukselle, sen on pyydettävä käyttöoikeustunnus valtuutuspalvelimelta. POST-pyyntö voi näyttää tältä:

Jos käyttäjän tunnistetiedot tarkistetaan, valtuutuspalvelin palauttaa sovellukselle käyttöoikeustunnuksen. Sovellus on nyt hyväksytty!

Huomautus: DigitalOcean ei tällä hetkellä tue kirjautumistietojen salasanatyyppiä, joten linkki osoittaa kuvitteelliseen valtuutuspalvelimeen osoitteessa "oauth.example.com".

Apurahan tyyppi: Asiakkaan tunnistetiedot

Asiakkaan valtuustietojen myöntämistyyppi tarjoaa sovellukselle tavan käyttää sitä henkilökohtainen tili palvelua. Esimerkkejä siitä, milloin tämä voi olla hyödyllistä, ovat, jos sovellus haluaa päivittää rekisteröidyn kuvauksensa tai uudelleenohjauksen URI:n tai käyttää muita palvelutilille tallennettuja tietoja API:n kautta.

Asiakkaan tunnistetietojen kulku

Sovellus pyytää käyttöoikeustunnusta lähettämällä valtuutustietonsa, asiakastunnuksensa ja asiakassalaisuuden valtuutuspalvelimelle. Esimerkki POST pyyntö voi näyttää tältä:

Jos asiakkaan tunnistetiedot tarkistetaan, valtuutuspalvelin palauttaa sovellukselle käyttöoikeustunnuksen. Tästä eteenpäin sovellus saa käyttää omaa tiliään!

Huomautus: DigitalOcean ei tällä hetkellä tue asiakkaan tunnistetietojen tarjontatyyppiä, joten linkki osoittaa kuvitteelliseen valtuutuspalvelimeen osoitteessa "oauth.example.com".

Esimerkki käyttöoikeustunnuksen käytöstä

Kun sovelluksella on käyttöoikeustunnus, se voi käyttää tunnusta päästäkseen käyttäjän tilille API:n kautta käyttörajoituksin, kunnes tunnus vanhenee tai se peruutetaan.

Tässä on esimerkki pyyntösovellusliittymästä kiemura. Huomaa, että se sisältää pääsytunnuksen:

curl -X POST -H "Authorization: Bearer ACCESS_TOKEN" "https://api.digitalocean.com/v2/$OBJECT" ;

Olettaen, että käyttöoikeustunnus on kelvollinen, API käsittelee pyynnön sen mukaisesti tekniset tiedot. Jos käyttöoikeustunnus on vanhentunut tai muuten virheellinen, API palauttaa virheilmoituksen "invalid_request".

Päivitä Token Flow

Kun käyttöoikeustunnus on vanhentunut, sen käyttäminen API-pyynnön tekemiseen johtaa "Virheellinen tunnus" -virheeseen. Jos tässä vaiheessa pyyntöön sisältyi päivitystunnus, kun alkuperäinen käyttöoikeustunnus annettiin, sitä voidaan käyttää pyytämään uusi käyttöoikeus valtuutuspalvelimelta. Tässä on esimerkki POST-pyyntö käyttämällä päivitystunnusta uuden käyttötunnuksen hankkimiseen:

Johtopäätös

Tämä päättää OAuth 2 -oppaamme. Sinulla pitäisi nyt olla hyvä käsitys siitä, miten OAuth 2 toimii ja milloin tiettyä valtuutuskulkua tulisi käyttää.

Jos haluat lisätietoja OAuth 2:sta, tutustu näihin hyödyllisiin resursseihin:

• Kuinka käyttää OAuth-todennusta DigitalOceanin kanssa käyttäjänä tai kehittäjänä
• DigitalOcean API -version 2 käyttäminen
• Valtuutuskehys

OAuth 2 on valtuutuskehys, jonka avulla sovellukset voivat saada rajoitetun pääsyn käytössä oleviin käyttäjätileihin HTTP-palvelut, esimerkiksi Facebookissa, GitHubissa ja DigitalOceanissa. Se toimii delegoimalla käyttäjän todennus palvelulle, joka isännöi käyttäjän tiliä, jolloin kolmannen osapuolen sovellus voi käyttää käyttäjän tiliä. OAuth 2 toimii verkko-, työpöytä- ja mobiilisovelluksissa.

Tämä artikkeli on tarkoitettu sovellusten kehittäjille, ja se sisältää yleiskatsauksen rooleista, valtuutustyypeistä ja tyypillisiä skenaarioita käyttämällä OAuthia 2.

Aloitetaan OAuth-rooleista!

OAuth-roolit

OAuth määrittelee neljä roolia:

• Resurssin omistaja
• Asiakas
• Resurssipalvelin
• Valtuutuspalvelin

Resurssin omistaja: Käyttäjä

Resurssin omistaja on käyttäjä, joka antaa luvan sovellus päästäksesi tilillesi. Sovelluksen käyttöoikeus käyttäjätilille on rajoitettu myönnettyjen valtuutusoikeuksien laajuuteen (esimerkiksi luku- tai kirjoitusoikeus).

Resurssi/valtuutuspalvelin: API

Resurssipalvelin tallentaa suoraan käyttäjätilien suojatut tiedot ja valtuutuspalvelin tarkistaa annettujen tietojen aitouden käyttäjä ja luo sitten valtuutustunnukset kohteelle sovellukset, jonka avulla sovellus pääsee käsiksi käyttäjätietoihin.

Sovelluskehittäjän näkökulmasta Palvelusovellusliittymä suorittaa samanaikaisesti sekä resurssipalvelimen että valtuutuspalvelimen roolia. Lisäksi pidämme näitä kahta roolia yhtenä ja kutsumme sitä Palvelu tai API.

Asiakas: Sovellus

Asiakas on sovellus joka haluaa päästä tilille käyttäjä. Ennen kuin käyttöoikeus voidaan tehdä, käyttäjän on valtuutettava sovellus ja API:n on hyväksyttävä valtuutus.

Nyt kun meillä on käsitys OAuthissa käytetyistä rooleista, katsotaanpa kaaviota, kuinka ne ovat vuorovaikutuksessa toistensa kanssa.

Harkitse vaiheiden järjestyksen kuvausta tässä kaaviossa:

1. Sovellus pyynnöt lähettäjältä käyttäjä valtuutus käyttää resurssipalvelinta.
2. Jos käyttäjä hyväksyy pyynnön, sovellus saa valtuutustuen.
3. Sovellus pyytää valtuutustunnusta osoitteesta valtuutuspalvelin(API) antamalla tietoja itsestään ja valtuutusluvan käyttäjältä.
4. Jos sovellus on todennettu ja valtuutuslupa on voimassa, valtuutuspalvelin(API) luo käyttöoikeustunnuksen sovellukselle. Valtuutusprosessi on valmis.
5. Sovellus pyytää resurssia osoitteesta resurssipalvelin(API), samalla kun se tarjoaa pääsytunnuksen todennusta varten.
6. Jos tunnus on voimassa, resurssipalvelin(API) tarjoaa pyydetyn resurssin sovellus.

Kuvatun prosessin vaiheiden todellinen järjestys voi vaihdella käytetyn valtuutusoikeuden tyypin mukaan, mutta yleensä prosessi näyttää kuvatulta. Seuraavaksi tarkastellaan erityyppisiä valtuutusoikeuksia.

Hakemuksen rekisteröinti

Ennen kuin aloitat OAuthin käytön sovelluksessasi, sinun on rekisteröitävä sovelluksesi palveluun. Tämä tehdään rekisteröitymällä palvelun verkkosivuston kehittäjä- tai API-osioon, jossa sinun on annettava seuraavat tiedot (mahdollisesti myös joitain tietoja sovelluksestasi):

• sovelluksen nimi
• Sovellussivusto
• Uudelleenohjauksen URL-osoite tai takaisinsoitto-URL-osoite

Uudelleenohjaus-URL on URL-osoite, johon palvelu uudelleenohjaa käyttäjän sovelluksesi valtuutuksen (tai valtuutuksen epäämisen) jälkeen.

Asiakastunnus ja asiakassalaisuus

Sovelluksen rekisteröinnin jälkeen palvelu luo asiakastunnukset - asiakastunnuksen ja asiakassalaisuuden. Asiakastunnus on julkisesti käytettävissä oleva merkkijono, jota palvelun API käyttää sovelluksen tunnistamiseen ja jota käytetään myös valtuutus-URL-osoitteiden luomiseen käyttäjille. Asiakassalaisuutta käytetään todentamaan sovelluksen identiteetti palvelun API:lle, kun sovellus pyytää pääsyä käyttäjän tilille. Asiakkaan salaisuuden tulisi olla vain sovelluksen ja API:n tiedossa.

Valtuutuksen lupa

SISÄÄN abstrakti protokollan kuvaus Yllä olevat neljä ensimmäistä vaihetta kattavat valtuutusluvan ja käyttötunnuksen luomisen. Valtuutusluvan tyyppi riippuu sovelluksen käyttämästä valtuutuspyyntömenetelmästä sekä siitä, mitä käyttöoikeustyyppejä API tukee. OAuth 2 määrittelee neljä erilaisia ​​tyyppejä, joista jokainen on hyödyllinen tietyissä tilanteissa:

• Valtuutuskoodi: Käytetään palvelinpuolen sovellusten kanssa.
• Implisiittinen: Mobiili- tai verkkosovellusten käyttämä (käyttäjän laitteessa toimivat sovellukset).
• Resurssin omistajan salasanan kirjautumistiedot: Luotetut sovellukset, kuten sovellukset, jotka ovat osa itse palvelua, käyttävät.
• Asiakkaan tunnistetiedot: Käytetään, kun sovellus käyttää API:ta.

Valtuutuslupatyyppi: Valtuutuskoodi

Valtuutuskoodi on yksi yleisimmistä valtuutuslupatyypeistä, koska se sopii hyvin palvelinsovelluksia , missä on sovelluksen lähdekoodi ja asiakkaan salaisuus ei ole ulkopuolisten ulottuvilla. Käsittely sisään tässä tapauksessa on rakennettu uudelleenohjaukseen, mikä tarkoittaa, että sovelluksen on kyettävä olemaan vuorovaikutuksessa käyttäjä agentti(user-agent), esimerkiksi verkkoselaimella, ja vastaanottaa käyttäjäagentin kautta uudelleenohjattuja API-valtuutuskoodeja.

Kuvataan prosessi kaaviossa:

Vaihe 1: Linkitä valtuutuskoodiin

• https://cloud.?response_type=code&client_id=CLIENT_ID &redirect_uri=CALLBACK_URL &scope=read

• : API-valtuutuksen päätepiste.
• client_id=ASIAKASTUNNUS: Sovelluksen asiakastunnus (tätä tunnusta käyttämällä API ymmärtää, mikä sovellus pyytää pääsyä).
• redirect_uri=CALLBACK_URL: URL-osoite, johon palvelu uudelleenohjaa käyttäjäagentin (selaimen) valtuutuskoodin antamisen jälkeen.
• vastaus_tyyppi=koodi: Ilmaisee, että sovellus pyytää pääsyä valtuutuskoodilla.
• soveltamisala = lue: määrittää sovelluksen käyttöoikeustason (tässä tapauksessa lukuoikeudet).

Vaihe 3: Sovellus vastaanottaa valtuutuskoodin

Jos käyttäjä valitsee "Valtuuta sovellus", palvelu ohjaa käyttäjäagentin (selaimen) kohteeseen Uudelleenohjauksen URL-osoite(uudelleenohjaus-URL), joka määritettiin asiakkaan rekisteröintivaiheessa (yhdessä valtuutuskoodi). Linkki näyttää samalta (in tässä esimerkissä Sovelluksen nimi on "dropletbook.com"):

• https://dropletbook.com/callback?code=AUTHORIZATION_CODE

Vaihe 4: Sovellus pyytää käyttöoikeustunnusta

Sovellus pyytää käyttöoikeustunnusta API:lta lähettämällä valtuutuskoodin ja todennustiedot (mukaan lukien asiakkaan salaisuus) palvelua. Alla on esimerkki POST-pyynnöstä DigitalOcean-tunnuksen vastaanottamiseksi:

• https://cloud.?client_id=CLIENT_ID &client_secret=CLIENT_SECRET &grant_type=authorization_code&code=AUTHORIZATION_CODE &redirect_uri=CALLBACK_URL

Vaihe 5: Sovellus vastaanottaa käyttöoikeustunnuksen

• ("access_token":"ACCESS_TOKEN ","token_type":"bearer","expires_in":2592000,"refresh_token":"REFRESH_TOKEN ","scope":"read","uid":100101,"info":( "nimi":"Mark E. Mark","email":" [sähköposti suojattu]"}}

Sovellus on nyt hyväksytty! Se voi käyttää tunnusta päästäkseen käyttäjätiliin palvelun API:n kautta annettuja rajoituksia pääsyä, kunnes tunnus vanhenee tai se peruutetaan. Jos käyttöoikeustunnuksen päivitystunnus on luotu, sitä voidaan käyttää uusien käyttöoikeuksien hankkimiseen vanhan tunnuksen vanhentuessa.

Valtuutuslupatyyppi: Implisiittinen

Implisiittistä valtuutuslupatyyppiä käyttävät mobiili- ja verkkosovellukset (verkkoselaimessa toimivat sovellukset), joissa tietosuoja asiakkaan salaisuus ei voida taata. Implisiittinen lupatyyppi perustuu myös käyttäjäagentin uudelleenohjaukseen, jossa käyttöoikeustunnus välitetään käyttäjäagentille edelleen sovellukselle lähettämistä varten. Tämä puolestaan ​​tekee tokenin käyttäjän saatavilla ja muut sovellukset käyttäjän laitteessa. Tämän tyyppinen valtuutusoikeus ei myöskään todenna sovelluksen identiteettiä, ja prosessi itse perustuu uudelleenohjaus-URL-osoitteeseen (joka on aiemmin rekisteröity palveluun).

Prosessi menee näin: sovellus pyytää käyttäjää valtuuttamaan itsensä, sitten valtuutuspalvelin välittää pääsytunnuksen käyttäjäagentille, joka välittää tunnuksen sovellukselle. Seuraavaksi kuvailemme prosessia yksityiskohtaisesti.

Vaihe 1: Implisiittinen valtuutuslinkki

Epäsuoralla valtuutuslupatyypillä käyttäjälle tarjotaan linkki, joka pyytää tunnuksen API:lta. Tämä linkki näyttää melkein samalta kuin linkki edellinen menetelmä(valtuutuskoodilla), paitsi pyydettäessä merkki koodin sijaan (huomaa vastaustyyppi"tunnus"):

• https://cloud.?response_type=token&client_id=CLIENT_ID &redirect_uri=CALLBACK_URL &scope=read

Vaihe 2: Käyttäjä valtuuttaa sovelluksen

Kun käyttäjä napsauttaa linkkiä, hänen on ensin kirjauduttava sisään vahvistaakseen henkilöllisyytensä (jos hän ei ole jo kirjautunut sisään, tietysti). Tämän jälkeen palvelu kehottaa käyttäjää antamaan sovellukselle valtuutuksen tai kieltämään sen pääsyn käyttäjätiliin. Alla on esimerkki tällaisesta dialogista:

Vaihe 3: Käyttäjäagentti hankkii käyttöoikeustunnuksen uudelleenohjaus-URI:sta

• https://dropletbook.com/callback#token=ACCESS_TOKEN

Vaihe 4: Käyttäjäagentti seuraa uudelleenohjaus-URI:tä

Käyttäjäagentti seuraa uudelleenohjaus-URI:tä samalla, kun se tallentaa käyttöoikeustunnuksen.

Vaihe 5: Sovellus suorittaa pääsytunnuksen hakukomentosarjan

Sovellus palauttaa web-sivun, joka sisältää komentosarjan käyttöoikeustunnuksen purkamiseksi käyttäjäagentin tallentamasta täydellisestä uudelleenohjaus-URI:sta.

Vaihe 6: Käyttöoikeustunnus välitetään sovellukselle

Käyttäjäagentti suorittaa käyttöoikeustunnuksen poimintakomentosarjan ja välittää sitten puretun tunnuksen sovellukselle.

Sovellus on nyt hyväksytty! Se voi käyttää tunnusta päästäkseen käyttäjätilille palvelun API:n kautta määritetyillä käyttörajoituksilla, kunnes tunnus vanhenee tai tunnus peruutetaan.

Valtuutusoikeustyyppi: resurssin omistajan kirjautumistiedot

Tämän tyyppisellä valtuutusluvalla käyttäjä toimittaa sovellukselle suoraan palvelussa olevat valtuutustietonsa (käyttäjätunnus ja salasana). Sovellus puolestaan ​​käyttää vastaanotettuja käyttäjätunnuksia saadakseen pääsytunnuksen palvelusta. Tämän tyyppistä valtuutuslupaa tulisi käyttää vain, kun muita vaihtoehtoja ei ole käytettävissä. Lisäksi tämäntyyppisiä käyttöoikeuksia tulisi käyttää vain, kun käyttäjä luottaa sovellukseen (esimerkiksi se on osa itse palvelua tai käyttäjän käyttöjärjestelmää).

Prosessi resurssin omistajan tunnistetiedoilla

Kun käyttäjä on antanut käyttöoikeustietonsa sovellukselle, sovellus pyytää käyttöoikeustunnusta valtuutuspalvelimelta. Esimerkki POST-pyynnöstä voi näyttää tältä:

• https://oauth.example.com/token?grant_type=salasana&käyttäjänimi=KÄYTTÄJÄNIMI &salasana=SALASANA &client_id=CLIENT_ID

Huomio: DigitalOcean ei tällä hetkellä tue valtuutuslupatyyppiä käyttämällä resurssin omistajan tunnistetietoja, joten yllä oleva linkki osoittaa kuvitteelliseen valtuutuspalvelimeen "oauth.example.com".

Valtuutuslupatyyppi: Asiakkaan tunnistetiedot

Asiakkaan tunnistetietojen valtuutusoikeustyyppi sallii sovelluksen käyttää sitä oma tili palvelua. Tästä voi olla hyötyä esimerkiksi silloin, kun sovellus haluaa päivittää omia palvelun rekisteröintitietojaan tai uudelleenohjata URI:ta tai päästä käsiksi muihin sovelluksen palvelutilille tallennettuihin tietoihin palvelun API:n kautta.

Asiakkaan tunnistetietojen käsittely

Sovellus pyytää käyttöoikeustunnusta lähettämällä valtuutustietonsa, asiakastunnuksensa ja asiakassalaisuuden valtuutuspalvelimelle. Esimerkki POST-pyynnöstä voi näyttää tältä:

• https://oauth.example.com/token?grant_type=client_credentials&client_id=CLIENT_ID &client_secret=CLIENT_SECRET

Huomio: DigitalOcean ei tällä hetkellä tue asiakkaan tunnistetietojen valtuutuslupatyyppiä, joten yllä oleva linkki osoittaa kuvitteelliseen valtuutuspalvelimeen "oauth.example.com".

Esimerkki käyttöoikeustunnuksen käytöstä

Kun sovellus on vastaanottanut käyttöoikeustunnuksen, se voi käyttää sitä päästäkseen käyttäjätiliin palvelun API:n kautta määritetyin käyttörajoituksin, kunnes tunnus vanhenee tai tunnus peruutetaan.

Alla on esimerkki API-pyynnöstä käyttämällä kiharaa. Huomaa, että se sisältää pääsytunnuksen:

• curl -X POST -H "Authorization: Bearer ACCESS_TOKEN "" https://api.site/v2/$OBJECT "

Jos käyttöoikeustunnus on kelvollinen, API käsittelee vastaanotetun pyynnön. Jos käyttöoikeustunnus on vanhentunut tai tunnus on virheellinen, API palauttaa virheilmoituksen "invalid_request".

Access Token Refresh

Kun käyttöoikeustunnus vanhenee, kaikki sitä käyttävät API-pyynnöt palauttavat virheellisen tunnuksen virheen. Jos käyttöoikeustunnusta luotaessa luotiin myös päivitystunnus, jälkimmäisen avulla voidaan hankkia uusi käyttöoikeustunnus valtuutuspalvelimelta.

Alla on esimerkki POST-pyynnöstä, joka käyttää oikeutta tunnuksen päivittämiseen uuden käyttöoikeustunnuksen saamiseksi:

• https://cloud.?grant_type=refresh_token&client_id=CLIENT_ID &client_secret=CLIENT_SECRET &refresh_token=REFRESH_TOKEN

Johtopäätös

Tämä päättää yleiskatsauksen OAuth 2:sta. Nyt olet yleinen idea miten OAuth 2 toimii ja milloin ja miten sitä käytetään olemassa olevia tyyppejä valtuutusoikeudet.

Jos haluat lisätietoja OAuth 2:sta, suosittelemme tutustumaan seuraaviin artikkeleihin.

|

OAuth 2 on valtuutusprotokolla, joka antaa sovelluksille rajoitetun HTTP-käytön käyttäjätileihin. Se välittää käyttäjän todennuksen tilit isännöivälle ja valtuuttavalle palvelulle kolmannen osapuolen sovelluksia ja antaa heille pääsyn käyttäjätiliin. OAuth 2 tarjoaa valtuutuksen verkkosovelluksille ja mobiililaitteille.

Tässä oppaassa tutustutaan OAuth 2:n rooleihin, valtuutustyyppeihin, kuluihin ja OAuth 2:n käyttötapauksiin.

OAuth-roolit

OAuthissa on neljä roolia:

1. Resurssin omistaja
2. Asiakas
3. Resurssipalvelin
4. Valtuutuspalvelin

Katsotaanpa jokaista roolia yksityiskohtaisemmin.

Resurssin omistaja: käyttäjä

Resurssin omistaja on käyttäjä, joka todentaa sovelluksen päästäkseen tililleen.

Sovellus rajoittaa pääsyä käyttäjätiliin käyttöoikeuksilla (eli oikeuksilla suorittaa tietty toiminto: lukea, kirjoittaa jne.).

Resurssi- ja valtuutuspalvelin: API

Resurssipalvelin tallentaa suojatut käyttäjätilit, ja valtuutuspalvelin tarkistaa käyttäjän tunnistetiedot ja antaa sitten sovelluksen käyttöoikeudet.

Sovelluskehittäjän näkökulmasta palvelun API suorittaa resurssipalvelimen ja valtuutuspalvelimen rooleja. Seuraavassa viitataan näihin rooleihin palveluna tai API:na.

Asiakas: sovellus

Asiakas on sovellus, joka haluaa käyttää käyttäjän tiliä. Ennen kuin se voi tehdä tämän, käyttäjän on oltava valtuutettu sovelluksessa ja API:n on vahvistettava valtuutus.

Protokollavirrat

OAuth-roolit ovat vuorovaikutuksessa keskenään seuraavasti:

• Sovellus pyytää käyttäjältä lupaa päästäkseen palveluresursseihin.
• Jos käyttäjä on valtuutettu sovelluksen pyynnöstä, sovellus saa luvat.
• Sovellus pyytää käyttöoikeustunnusta valtuutuspalvelimelta (API).
• Jos sovellus on todennettu ja sen tunnistetiedot ovat kelvollisia, valtuutuspalvelin (API) antaa sille käyttöoikeustunnuksen. Valtuutus on valmis.
• Sovellus pyytää resurssia resurssipalvelimelta (API) ja tarjoaa käyttöoikeustunnuksen todennusta varten.
• Jos käyttöoikeustunnus on kelvollinen, resurssipalvelin (API) palvelee sovelluksen resursseja.

Hakemuksen rekisteröinti

Ennen kuin voit käyttää OAuthia sovelluksessa, sinun on rekisteröitävä sovellus. Tämä tehdään palvelun verkkosivuston Kehittäjä- tai API-osiossa olevalla rekisteröintilomakkeella, jossa sinun on annettava seuraavat tiedot:

• Sovelluksen nimi;
• Sovellussivusto;
• Takaisinsoitto-URL tai uudelleenohjaus-URI (tähän palvelu ohjaa käyttäjän sen jälkeen, kun hän on läpäissyt (tai epäonnistunut) valtuutuksen; tämä sovelluksen osa käsittelee valtuutuskoodeja tai käyttöoikeuksia).

Asiakastunnus ja salainen avain

Hakemuksen rekisteröinnin jälkeen palvelu antaa sinulle sovelluksen tunnistetiedot, jotka löytyvät asiakastunniste- ja asiakassalaisuuskentistä. Asiakastunnus on julkinen merkkijono, jota palvelun API käyttää sovelluksen tunnistamiseen; sitä käytetään myös valtuutus-URL-osoitteiden luomiseen. Client Secret sallii palvelun API:n todentaa sovelluksen, kun se pyytää pääsyä käyttäjätiliin. Nämä arkaluontoiset tiedot tallennetaan sovelluksen ja API:n väliin.

Valtuutusoikeudet

Valtuutusoikeudet riippuvat menetelmästä, jota sovellus käyttää valtuutuksen pyytämiseen, sekä API:n tukemista käyttöoikeustyypeistä. OAuth 2 määrittää neljän tyyppisiä käyttöoikeuksia, joista jokainen on hyödyllinen eri tapauksissa:

1. Vahvistuskoodi: Käytetään palvelinpuolen sovelluksissa.
2. Implisiittinen pääsy: käytetty vuonna web ja mobiili sovellukset (käyttäjän laitteessa toimivat sovellukset).
3. Asiakkaalle salasanan antaminen: käytetään etukäteen suojattuja sovelluksia(esimerkiksi palvelun omistamissa sovelluksissa).
4. Asiakkaan oikeudet: pääsy sovellusliittymään.

vahvistuskoodi

Vahvistuskoodi on yleisin valtuutustyyppi, joka on optimoitu palvelinpuolen sovelluksille, joissa lähdekoodi on suljettu ja Client Secret ei ole ulkopuolisten saatavilla. Tämä kulku on uudelleenohjauspohjainen, mikä tarkoittaa, että sovelluksen on kyettävä olemaan vuorovaikutuksessa käyttäjäagentin (eli käyttäjän verkkoselaimen) kanssa ja vastaanottamaan API-valtuutuskoodeja, jotka reititetään käyttäjäagentin kautta.

Vahvistuskoodivirta näyttää tältä:

1. Käyttäjä saa linkin vahvistuskoodiin.
2. Käyttäjä on valtuutettu. Klikkaamalla linkkiä käyttäjä vahvistaa tietojen aitouden. Jos annetut tiedot ovat virheellisiä, käyttäjältä evätään valtuutus.
3. Sovellus saa vahvistuskoodin. Palvelu ohjaa käyttäjäagentin vahvistuskoodin kanssa URI:hen, joka määritettiin asiakkaan rekisteröityessä.
4. Sovellus pyytää API:lta käyttöoikeustunnusta, joka tarjoaa vahvistuskoodin ja valtuutustiedot, mukaan lukien asiakkaan salaisuuden.
5. Sovellus saa käyttöoikeustunnuksen, jos valtuutus on voimassa.

Implisiittisen pääsyn virtaus

Implisiittistä pääsyvirtaa käyttävät mobiilisovellukset tai verkkosovellukset, joissa asiakassalaisuuden luottamuksellisuutta ei voida taata. Tämä kulku on myös uudelleenohjauspohjainen, mutta käyttäjäagentti vastaanottaa käyttöoikeustunnuksen ja välittää sen sitten sovellukselle. Näin se voidaan nähdä käyttäjälle tai muille käyttäjän laitteessa oleville sovelluksille. Lisäksi tämä kulku ei todenna sovellusta, se tekee sen URI:n avulla (joka on rekisteröity palveluun).

Päivitystunnuksia ei tueta implisiittistä pääsyä varten.

Implisiittisen pääsyn kulku toimii periaatteessa näin: käyttäjää pyydetään kirjautumaan sovellukseen, valtuutuspalvelin välittää pääsytunnuksen käyttäjäagentille, joka välittää sen sovellukselle. Yksityiskohtaisemmin tämä prosessi näyttää tältä:

1. Käyttäjä saa implisiittisen pääsylinkin, joka pyytää tunnuksen API:lta.
2. Käyttäjä valtuutetaan napsauttamalla linkkiä. Jos käyttäjä ei voi kirjautua sisään, häneltä estetään pääsy.
3. Käyttäjäagentti saa käyttöoikeustunnuksen ja uudelleenohjaus-URI:n.
4. Käyttäjäagentti seuraa uudelleenohjaus-URI:tä.
5. Sovellus lähettää komentosarjan pääsytunnuksen hakemiseksi. Sovellus palauttaa verkkosivun, jossa on komentosarja, joka voi purkaa pääsytunnuksen uudelleenohjaus-URI:sta.
6. Sovellus saa käyttöoikeustunnuksen. Valtuutus on valmis.

Asiakkaalle salasanan antaminen

Tämä tyyppi tarkoittaa, että käyttäjä välittää tunnistetiedot suoraan sovellukselle, joka käyttää niitä pääsytunnuksen hankkimiseen. Tätä tyyppiä tulisi tukea vain valtuutuspalvelimessa. Lisäksi sitä tulee käyttää vain, jos sovellukseen voi luottaa (esimerkiksi se kuuluu palveluun tai käyttäjän käyttöjärjestelmään).

Saatuaan käyttäjän tunnistetiedot sovellus pyytää käyttöoikeustunnusta valtuutuspalvelimelta. Jos valtuustiedot ovat oikein, valtuutuspalvelin tarjoaa käyttöoikeustunnuksen. Valtuutus on valmis.

Asiakkaan tunnistetiedot

Tämän tyypin avulla sovellus voi muodostaa yhteyden omaan palvelutiliinsä. Tämä työnkulku on hyödyllinen, jos sovellus haluaa päivittää rekisteröidyn kuvauksensa tai uudelleenohjata URI:n tai käyttää muita palvelutilille tallennettuja tietoja.

Sovellus pyytää käyttöoikeustunnusta lähettämällä valtuustietonsa, asiakastunnuksensa ja asiakassalaisuuden. . Jos valtuustiedot ovat oikein, valtuutuspalvelin tarjoaa käyttöoikeustunnuksen. Valtuutus on valmis.

Käyttöoikeustunnusten käyttö

Kun sovellus vastaanottaa käyttöoikeustunnuksen, se voi käyttää sitä käyttäjän tiliin pääsyyn API:n kautta.

Jos tunnus on kelvollinen, API käsittelee pyynnön. Jos tunnus on virheellinen, API antaa invalid_request -virheen.

Flow virkistävällä tunnuksella

Kun käyttöoikeus vanhenee, API antaa invalid_request -virheen. Jos sovellus on saanut päivitystunnuksen käyttöoikeustunnuksen mukana, se voi nyt pyytää uutta käyttöoikeustunnusta valtuutuspalvelimelta sen avulla.

Olet nyt perehtynyt OAuth 2:n perusteisiin.

Tunnisteet: ,

1. Sisäänrakennetun selaimen avaaminen kirjautumissivulla
2. Käyttäjää pyydetään vahvistamaan, että oikeudet on myönnetty.
3. Jos käyttäjä suostuu, selain ohjataan tynkäsivulle fragmentissa (#:n jälkeen), jonka URL-osoite on lisätty pääsytunnus
4. Sovellus sieppaa uudelleenohjauksen ja vastaanottaa pääsytunnus sivun osoitteesta

Tämä vaihtoehto edellyttää selainikkunan nostamista sovelluksessa, mutta se ei vaadi palvelinosaa ja lisäpuhelu palvelimelta palvelimelle vaihtoa varten valtuutuskoodi päällä pääsytunnus.

Esimerkki

Avaa selain kirjautumissivulla:
> HANKI /oauth/authorize?response_type=token&client_id=464119 HTTP/1.1 > Isäntä: connect.mail.ru

Kun käyttäjä on myöntänyt käyttöoikeudet, tapahtuu uudelleenohjaus tavalliselle tynkäsivulle, Mail.Ru:lle tämä on connect.mail.ru/oauth/success.html:
< HTTP/1.1 302 Found < Location: http://connect.mail.ru/oauth/success.html#access_token=FJQbwq9&token_type=bearer& expires_in=86400&refresh_token=yaeFa0gu

Sovelluksen tulee siepata viimeinen uudelleenohjaus ja saada se osoitteesta pääsytunnus ja käyttää sitä suojattujen resurssien käyttämiseen.

Valtuutus kirjautumistunnuksella ja salasanalla

Valtuutus kirjautumistunnuksella ja salasanalla on yksinkertainen POST-pyyntö, jonka seurauksena se palautuu pääsytunnus. Tämä järjestelmä ei ole uusi, mutta se sisältyy yleisstandardiin ja sitä suositellaan käytettäväksi vain silloin, kun muita valtuutusvaihtoehtoja ei ole saatavilla.

Esimerkki

> POST /oauth/token HTTP/1.1 > Isäntä: connect.mail.ru > Sisältötyyppi: application/x-www-form-urlencoded > > grant_type=password&client_id=31337&client_secret=deadbeef&username=api@corp.mail.ru& password= qwerty< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"SlAV32hkKG", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"8xLOxBtZp8", < }
Kuvaus spesifikaatiossa

Aiemman valtuutuksen palauttaminen

Yleensä, pääsytunnus on rajoitettu säilyvyysaika. Tästä voi olla hyötyä esimerkiksi, jos se välitetään avoimia kanavia. Jotta käyttäjä ei pakoteta kirjautumaan sisään vanhenemisen jälkeen pääsytunnus"ja kaikissa yllä olevissa vaihtoehdoissa sen lisäksi pääsytunnus"ehkä tulla takaisin päivitä tunnus. Voit käyttää sitä saadaksesi pääsytunnus HTTP-pyynnön avulla, joka on samanlainen kuin valtuutus kirjautumistunnuksella ja salasanalla.

Esimerkki

> POST /oauth/token HTTP/1.1 > Isäntä: connect.mail.ru > Sisältötyyppi: application/x-www-form-urlencoded > > grant_type=refresh_token&client_id=31337&client_secret=deadbeef&refresh_token=8xLOxBt< HTTP/1.1 200 OK < Content-Type: application/json < < { < "access_token":"Uu8oor1i", < "token_type":"bearer", < "expires_in":86400, < "refresh_token":"ohWo1ohr", < }