OAuth: kuvaus protokollasta yksinkertaisella ja ymmärrettävällä kielellä. OAuth-toiminnon esittely yksinkertaisella sovelluksella esimerkkinä. Moniprosessi- ja hajautetut sovellukset

Vaihe 1. Sivuston rekisteröinti

Seuraa linkkiä http://api.mail.ru/sites/my/add ja rekisteröi sivustomme. Lataa seuraavaksi ja lataa osoitteeseen ftp-tiedosto Receiver.html, jota tarvitaan sivustomme vahvistamiseen.
Rekisteröinnin jälkeen meille annetaan 3 parametria:

• Yksityinen avain
• Salainen avain

Olemme vain kiinnostuneita ID Ja Salainen avain(Yksityinen avain tarvitaan asiakas-palvelin-mallissa). Tallennetaan ne sisään asetustiedosto skriptimme seuraavilla nimillä.

$APP_ID; $APP_SECRET;

Vaihe 2. Vastaanota koodi

Saadaksesi koodin sinun tulee ottaa yhteyttä seuraavaan osoitteeseen: connect.mail.ru/oauth/authorize, välittää sen $_GET parametrit:

• Asiakastunnus- Sivuston tunnus
• vastauksen_tyyppi- 3 vaihtoehtoa, joista valita. merkki- API:n käyttöoikeus tarjotaan vain javascriptin kautta, koodi_ja_tunnus- API-käyttö palvelimen ja javascriptin kautta, koodi- pääsy API:hen palvelimen kautta. Meidän tapauksessamme se tulee olemaan koodi.
• redirect_uri- Vastaanottavan sivun vastaustyypin osoite
• soveltamisalaan- Sovellusoikeudet. Parametri on valinnainen ja meidän tapauksessamme redundantti. Jos päätät pyytää oikeuksia, muista, että kaikki käyttäjät eivät halua siirtää yksityisiä tietojaan sinulle, joten sinun ei tarvitse käyttää laajuusparametria vain valtuutusta varten.

Mukavuuden vuoksi erotetaan logiikka linkin luomiseksi koodin vastaanottamiseksi ja sen käsittelemiseksi:
example.com/login.php - luo linkki koodin vastaanottamista varten (pääasiassa linkki valtuutusta varten).
example.com/auth.php - koodinkäsittely.

Lopullinen pyyntö näyttää tältä:

$uudelleenohjaus_uri = urlencode("http://example.com/auth.php"); $login_url = "https://connect.mail.ru/oauth/authorize?client_id=($APP_ID)&response_type=code&redirect_uri=($redirect_uri)";

Kun menee tähän osoitteeseen, Mail.ru:n luvaton käyttäjä näkee:

Jos käyttäjä on valtuutettu Mail.ru:ssa, hän näkee saman ikkunan, mutta ilman kirjautumistunnusta ja salasanaa.
Nyt käyttäjällä on kaksi vaihtoehtoa: sallia ja hylätä. Kiellättäessä käyttäjä ohjataan kohdassa määritetylle sivulle redirect_uri ilmoittaa virheestä.

Jos kaikki meni niin kuin pitää ja käyttäjä on antanut sivustolle pääsyn tietoihinsa, käyttäjä ohjataan sivulle redirect_uri(http://example.com/auth.php), $_ GET-parametri koodi.
Tallennetaan se nimen alle

$APP_CODE;

Vaihe 3. Tokenin ja uid:n hankkiminen

Tätä varten sinun on otettava yhteyttä osoitteeseen connect.mail.ru/oauth/token, välittää sille parametrit:

• Asiakastunnus($APP_ID)
• client_salaisuus($APP_SECRET)
• grant_type(valtuutuskoodi)
• koodi($APP_CODE)
• redirect_uri($redirect_uri vaiheesta 2)

Kaikki parametrit vaaditaan. Redirect_uri on täsmälleen sama kuin mitä käytimme vaiheessa 2.

Tokenin vastaanottamispyyntö voidaan tehdä vain kautta POST-pyyntö, joten cURL auttaa:

$ch = curl_init(); $url = "https://connect.mail.ru/oauth/token"; $fields = Array("client_id" => $APP_ID, "client_secret" => $APP_SECRET, "grant_type" => "authorization_code", "code" => $APP_CODE, "redirect_uri" => urlencode(redirect_uri)); foreach($kentät muodossa $avain => $arvo)( $kentät_merkkijono .= $avain . "=" . $arvo . "&"; ) rtrim($kentät_merkkijono, "&"); curl_setopt($ch, CURLOPT_URL, $url); curl_setopt($ch, CURLOPT_RETURNTRANSFER, 1); curl_setopt($ch, CURLOPT_POST, true); curl_setopt($ch, CURLOPT_POSTFIELDS, $fields_string); $tulos = curl_exec($ch); curl_close($ch); $arr = json_decode($tulos, tosi); //tai $arr = (joukko) json_decode($tulos). Tietääkö joku muuten onko eroa? $tunnus = $arr["pääsytunnus"]; $uid = $arr["x_mailru_vid"];

Vaihe 4. Hanki käyttäjätiedot

Vastaanottamisen jälkeen merkki Ja uid sivusto saa kauan odotetun pääsyn Mail.ru API:hen osoitteessa www.appsmail.ru/platform/api.
Mutta se ei ole niin yksinkertaista; jokainen API-pyyntö on allekirjoitettava. Allekirjoitus (tässä tapauksessamme) on tiiviste, joka on laskettu md5-algoritmilla lajitellusta Aakkosjärjestys merkkijonoja API:lle välitetyistä parametreista ilman erotinta & Ja Salainen avain.
Esimerkiksi:

Md5("app_id=423004method=friends.getsession_key=be6ef89965d58e56decdfacb9b62bdaa" . $APP_SECRET);

Mail.ru tarjoaa 2 allekirjoitusvaihtoehtoa: asiakas-palvelin ja palvelin-palvelin. Erona on, että toinen lähestymistapa on turvallisempi. Tätä aiomme käyttää. Tätä varten sinun on määritettävä API-pyyntösi turvallinen=1.

Suoritetaan pyyntö saada henkilökohtaisia ​​tietoja Mail.ru-käyttäjältä menetelmällä users.getInfo.

$request_params = Array("app_id" => $APP_ID, "uids" => $uid, "method" => "users.getInfo", "secure" => 1, "session_key" => $tunnus); //Parametrit on lajiteltava aakkosjärjestykseen ksort($request_params); $params = ""; foreach ($request_params as $key => $value) ($params .= "$key=$value"; ) //Palvelinten välisessä mallissa allekirjoitus näyttää tältä $sig = md5($ parametrit $APP_SECRET); //Muotoile pyyntö $url = "http://www.appsmail.ru/platform/api?method=users.getInfo&app_id=($APP_ID)&session_key=($token)&sig=($sig)&uids=($uid ) &secure=1"; $vastaus = file_get_contents($url); $info = (joukko) json_decode($response); $info = $info; //koko tulos print_r($info);

Siinä kaikki. Näin ollen saimme tarvittavat tiedot käyttäjän syöttämiseksi tietokantaan. Kaikki jatkoprosessi on kuvattu jo useita kertoja mm. Joten en näe mitään järkeä kuvailla sitä.

PROFIT!!1 Kaikkea hyvää. Jos artikkeli osoittautuu mielenkiintoiseksi, voin myös analysoida palvelimen oAuth 2.0 -valtuutusprosessia Vkontaktelle ja Facebookille.

Vuonna 2010 työ aloitettiin kokonaan uusi versio OAuth 2.0 -protokolla, joka ei ole taaksepäin yhteensopiva OAuth 1.0:n kanssa. Lokakuussa 2012 OAuth 2.0 -kehys julkaistiin RFC 6749:ssä ja tunnuksen siirtotien käyttö RFC 6750:ssä, molemmat standardit seuraavat kommenttipyyntöjä. Muita RFC:itä kehitetään edelleen.

OAuth 2.0:n luomiselle oli useita edellytyksiä. Ensinnäkin OAuth on melko ei-triviaali käyttää asiakkaan puolella. Yksi uuden OAuthin kehittämisen tavoitteista on yksinkertaistaa kehitystä asiakassovellukset. Toiseksi huolimatta siitä, että standardissa on otettu käyttöön kolme menetelmää (kutsutaan virtauksiksi) tunnuksen (ainutlaatuisen tunnisteen) hankkimiseksi valtuutusta varten: verkkosovelluksille, työpöytäasiakkaille ja mobiiliasiakkaat Itse asiassa kaikki kolme menetelmää yhdistetään yhdeksi. Ja kolmanneksi, protokolla osoittautui huonosti skaalautuvaksi. On tarkoitus lisätä:

• 6 uutta striimiä.

User-Agent Flow - asiakkaille, jotka toimivat käyttäjäagentin (yleensä verkkoselaimen) sisällä. Web Server Flow - asiakkaille, jotka ovat osa web-palvelinsovellusta, joihin pääsee HTTP-pyyntöjen kautta. Device Flow - Sopii asiakkaille, jotka toimivat rajoitetuilla laitteilla, mutta missä loppukäyttäjä Sillä on erillinen pääsy toisen tietokoneen tai laitteen selaimeen. Käyttäjätunnus- ja salasanavirta (Käyttäjänimi ja Salasana Flow - Käytetään tapauksissa, joissa käyttäjä luottaa asiakkaan käsittelemään valtuustietojaan, mutta ei silti ole toivottavaa sallia asiakkaan tallentaa käyttäjätunnusta ja salasanaa. Tämä kulku sopii vain, kun käyttäjän ja asiakkaan välillä on korkea luottamus. Client Credentials Flow - Asiakas käyttää valtuustietojaan tunnuksen hankkimiseen. Assertion Flow - Asiakas lähettää väitteen, kuten SAML-vahvistuksen, valtuutuspalvelimelle vastineeksi tunnuksesta. Sovellukset käynnissä pöytätietokone tai mobiililaite voidaan toteuttaa käyttämällä yllä olevia säikeitä.

• Kantajatunnus.

Valtuutusmenetelmä on samanlainen olemassa oleva menetelmä lupa evästeiden avulla. Tässä tapauksessa merkkiä käytetään suoraan salaisuutena (itse tokenin saaminen valtuuttaa asiakkaan) ja se lähetetään HTTPS:n kautta. Tämän avulla voit käyttää API:a yksinkertaiset skriptit(esimerkiksi käyttämällä cURL-osoitetta).

• Yksinkertaistettu allekirjoitus.

Allekirjoitusta on yksinkertaistettu huomattavasti erikoisanalyysin, koodauksen ja parametrien lajittelun välttämiseksi.

• Lyhytikäiset rahakkeet, joilla on pitkäaikainen valtuutus.

Sen sijaan, että antaisit pitkäikäisen merkin (joka pitkä aika saattaa vaarantua), palvelin tarjoaa lyhytaikaisen pääsyn ja pitkän aikavälin mahdollisuuden päivittää tunnuksen ilman käyttäjän toimia.

• Roolien erottelu.

Eri palvelimet voivat olla vastuussa valtuutuksesta ja API:n pääsyn tarjoamisesta.

On syytä huomata, että vaikka OAuth 2.0 -standardia ei ole vielä hyväksytty, jotkut palvelut käyttävät sitä jo. Esimerkiksi Graph API sosiaalinen verkosto Facebook tukee vain OAuth 2.0:aa.

Ero OAuthin ja OpenID:n välillä

On olemassa väärinkäsitys, että OAuth on OpenID-protokollan laajennus. Itse asiassa tämä ei ole totta. Vaikka OpenID:llä ja OAuthilla on monia yhtäläisyyksiä, jälkimmäinen on erillinen protokolla, joka ei liity mitenkään OpenID:hen.

Aikaleima ja nonce

Pyyntöjen uhan estämiseksi uudelleenkäyttö OAuth käyttää nonce-merkkiä ja aikaleimaa. Termi "nonce" tarkoittaa, että annettu aika käytetään kerran ja se on ainutlaatuinen satunnainen kirjain- ja numerojono, joka on tarkoitettu yksilöimään jokainen allekirjoitettu pyyntö. Kun jokaiselle pyynnölle on yksilöllinen tunniste, palveluntarjoaja pystyy estämään uudelleenkäyttöpyynnöt. Tämä tarkoittaa, että asiakas luo ainutlaatuisen merkkijonon jokaiselle palvelimelle lähettämänsä pyynnölle, ja palvelin pitää kirjaa kaikista käytetyistä poikkeuksista estääkseen niitä käyttämästä toista kertaa.

Noncen käyttäminen voi olla erittäin kallista palvelimelle, koska ne vaativat pysyvä varastointi kaikki saaneet kerran. Toteutuksen helpottamiseksi OAuth lisää aikaleiman jokaiseen pyyntöön, jolloin palvelin voi tallentaa nonce-tunnisteen vain rajoitetun ajan. Kun pyyntö saapuu aikaleimalla, joka on aikaisempi kuin tallennettu aika, se hylätään, koska palvelimella ei ole enää noncea tästä ajasta.

Valtuustiedot ja Tokenit

OAuth käyttää kolmenlaisia ​​valtuuksia: asiakkaan tunnistetiedot (kuluttaja avain ja salaiset tai asiakkaan valtuustiedot), väliaikaiset valtuustiedot (pyyntötunnus ja salaiset tai väliaikaiset valtuustiedot) ja tunnukset (käyttöoikeus ja salaiset tai valtuustiedot).

Asiakkaan tunnistetietoja käytetään asiakkaan todentamiseen. Tämän avulla palvelin voi kerätä tietoja asiakkaista. Palveluillaan palvelin tarjoaa joillekin asiakkaille erikoiskäsittelyä, kuten kuristuksen vapaa pääsy tai anna resurssin omistajalle lisää yksityiskohtainen tieto asiakkaista, jotka yrittävät käyttää suojattuja resurssejaan. Joissakin tapauksissa asiakkaan tunnistetiedot eivät ehkä ole turvallisia ja niitä voidaan käyttää vain tiedotustarkoituksiin esimerkiksi työpöytäsovelluksissa.

Tunnusta käytetään resurssin omistajan nimen ja salasanan sijasta. Resurssin omistaja ei jaa valtuustietojaan asiakkaan kanssa, vaan valtuuttaa palvelimen antamaan asiakkaalle tunnuksen – erityinen tunnisteluokka, joka edustaa käyttöoikeuden myöntämistä. Asiakas käyttää tokenia päästäkseen suojattuun resurssiin tietämättä resurssin omistajan salasanaa.

Tunnus koostuu tunnisteesta, yleensä (mutta ei aina) satunnaisesta kirjaimien ja numeroiden joukosta, joka on ainutlaatuinen ja vaikea arvata, sekä avaimesta, joka suojaa tunnuksen käytöltä tuntemattomat. Tunnus on laajuudeltaan ja kestoltaan rajoitettu, ja resurssin omistaja voi peruuttaa sen milloin tahansa vaikuttamatta muihin muille asiakkaille myönnettyihin tunnuksiin.

OAuth-valtuutusprosessi käyttää myös joukkoa väliaikaisia ​​tunnistetietoja, joita käytetään valtuutuspyynnön määrittämiseen. Tilapäiset tunnistetiedot tarjoavat lisää joustavuutta ja turvallisuutta erityyppisten asiakkaiden (verkko, työpöytä, mobiili jne.) tarpeisiin.

Miten OAuth toimii

Miten OAuth-protokolla toimii

Selitämme OAuth-protokollan toimintaa esimerkin avulla. Oletetaan, että käyttäjä (resurssin omistaja) haluaa tulostaa valokuvansa (resurssit), jotka on ladattu sivustolle "photos.example.net" (palvelin) käyttämällä tulostuspalvelua "printer.example.net" (asiakas).

1. HTTPS-protokollaa käyttävä asiakas lähettää palvelimelle pyynnön, joka sisältää asiakastunnisteen, aikaleiman, takaisinsoittoosoitteen, johon tunnus tulee palauttaa, käytetyn digitaalisen allekirjoituksen tyypin ja itse allekirjoituksen.
2. Palvelin kuittaa pyynnön ja vastaa asiakkaalle Access Tokenilla ja osalla jaettua salaisuutta.
3. Asiakas siirtää tunnuksen resurssin omistajalle (käyttäjälle) ja ohjaa sen palvelimelle valtuutusta varten.
4. Palvelin, saatuaan käyttäjältä tunnuksen, kysyy häneltä kirjautumistunnusta ja salasanaa, ja jos todennus onnistuu, pyytää käyttäjää vahvistamaan asiakkaan pääsyn resursseihin (valtuutus), minkä jälkeen palvelin ohjaa käyttäjän uudelleen asiakas.
5. Asiakas välittää tunnuksen palvelimelle TLS:n kautta ja pyytää pääsyä resursseihin.
6. Palvelin kuittaa pyynnön ja vastaa asiakkaalle uudella pääsytunnuksella.
7. Uuden tunnuksen avulla asiakas ottaa yhteyttä palvelimeen saadakseen resursseja.
8. Palvelin kuittaa pyynnön ja tarjoaa resursseja.

Tämä esimerkki kuvaa kulun valtuutuskoodilla (Authorization Code Flow). Lisäksi OAuth 2.0 -standardi kuvaa seuraavat työt:

• Implisiittinen apurahavirta

Ero vahvistuskoodin kulusta on se, että palvelin ei todenna asiakasta ja palvelin myöntää pääsytunnuksen valtuutuspyynnön jälkeen.

• Päivitetään vanhentunut käyttöoikeustunnus

Erot tästä virrasta annetusta esimerkistä seuraavasti: vaiheessa 2 palvelin, jolla on pääsytunnuksen lisäksi rajoitettu aika elämä, antaa virkistysmerkin; Vaiheessa 8 palvelin tarkistaa, onko käyttöoikeustunnus kelvollinen (eli käyttöiän vanhentuessa) ja tästä riippuen joko myöntää pääsyn resursseihin tai vaatii pääsytunnuksen päivityksen (joka annetaan esitettäessä päivitystunnus).

• Resurssin omistajan salasanan kirjautumistietojen kulku

Tässä kulussa resurssin omistaja antaa asiakkaalle kirjautumistunnuksen ja salasanan, hän välittää ne palvelimelle ja vastaanottaa resurssien käyttötunnuksen. Huolimatta siitä, että tämä toimintatapa on jossain määrin ristiriidassa protokollan luomisen käsitteen kanssa, se on kuvattu spesifikaatiossa.

• Asiakkaan kirjautumistietojen kulku

SISÄÄN tämä tila miten protokolla toimii, palvelin tarjoaa pääsytunnuksen, kun asiakas on lähettänyt käyttäjänsä ja salasanansa, jotka valtuutuspalvelin on aiemmin asettanut (määrittely ei täsmennä kuinka tarkasti). Itse asiassa asiakas käy välittömästi läpi sekä valtuutuksen että autentikoinnin.

OAuth tukee kahta tapaa todentaa asiakkaalta tulevat viestit: HMAC -SHA1 ja RSA -SHA1 . Viestejä voi lähettää ilman allekirjoitusta, jolloin allekirjoitustyyppikentässä näkyy "pelkkä teksti". Mutta tässä tapauksessa spesifikaation mukaan yhteys asiakkaan ja palvelimen välille on muodostettava SSL:n tai TLS:n kautta.

OAuthia käyttävät portaalit

Keskustelu

Heinäkuussa 2012 OAuth 2.0 -standardin nykyinen toimittaja Eran Hammer ilmoitti eroavansa kolmen vuoden työskentelyn jälkeen uuden standardin parissa ja pyysi nimensä poistamista teknisistä tiedoista. Hän on kertonut näkemyksistään verkkosivuillaan. Myöhemmin hän piti esityksen. .

Huomautuksia

Katso myös

Linkit

Wikimedia Foundation. 2010.

Sovelluksen luomisen aikana sinun on määritettävä redirect_uri, jota käytetään OAuth-valtuutuksen aikana.

https://connect.ok.ru/oauth/authorize? Asiakastunnus=(asiakastunnus)& soveltamisalaan=(laajuus)& vastauksen_tyyppi=((vastauksen_tyyppi))& redirect_uri=(uudelleenohjausUri)& layout=(asettelu)& osavaltio=(osavaltio)

Nimi	Edellytetään	Kuvaus
Asiakastunnus	Joo	Sovellustunnus
soveltamisalaan	Joo	Pyydetyt sovellusoikeudet erotettuna merkillä ';'. Katso sovelluksen käyttöoikeudet
vastauksen_tyyppi	Joo	Palvelimen vastauksen tyyppi, ilmoita koodi
redirect_uri	Joo	URI, johon pääsytunnus lähetetään. URI:n on vastattava merkki kerrallaan yhtä sovellusasetuksiin rekisteröidyistä URI:ista. URI:n '?' (kysely) -merkin jälkeistä osaa ei oteta huomioon varmentamisessa, mutta on suositeltavaa käyttää tilaparametria dynaamisesti muuttuvien tietojen lähettämiseen.
layout	Ei	Valtuutusikkunan ulkoasu: * w – (oletus) tavallinen ikkuna varten täysversio verkkosivusto; * m – ikkuna mobiilivaltuutusta varten; * a – yksinkertaistettu ikkuna mobiilivaltuutusta varten ilman otsikkoa.
osavaltio	Ei	Tilaparametri. Se välitetään muuttumattomana osoitteeseen redirect_uri. Mahdollistaa mielivaltaisten tietojen siirtämisen eri OAuth-vaiheiden välillä ja suojauksen xsrf:ltä.

2. Salli käyttöoikeudet

Jos käyttäjä on aiemmin myöntänyt sovellukselle kaikki laajuusparametrissa määritellyt oikeudet, ikkuna sulkeutuu automaattisesti ja lisävahvistus ei vaadita käyttäjältä.

Luotua URL-osoitetta napsautettuaan käyttäjän tulee syöttää käyttäjätunnus ja salasana, ellei hän ole sitä aiemmin tehnyt. Sivustolle kirjautumisen jälkeen häntä pyydetään valtuuttamaan sovellus ja vahvistamaan pyydetyt oikeudet:

3. Koodin hankkiminen

Kun valtuutus on vahvistettu, käyttäjä ohjataan valtuutusikkunaa avattaessa määritettyyn redirect_uriin, jonka GET-parametrit sisältävät pääsyavaimen koodin sekä tilan, onko se määritetty vaiheessa 1:

(uudelleenohjaus_uri)? koodi=(koodi)& osavaltio=(osavaltio)

Tuloksena oleva koodiparametri on voimassa 2 minuuttia.

(redirect_uri)# virhe=(virhe)& osavaltio=(osavaltio)

4. Access_tokenin hankkiminen

Saadaksesi access_token, sinun on tehtävä POST-pyyntö sivustosi palvelimelta API:lle osoitteessa URL:

koodi=(koodi)& Asiakastunnus=(asiakastunnus)& client_salaisuus=(asiakassalaisuus)& redirect_uri=(uudelleenohjaus_uri)& grant_type=(grant_type)

Palvelimen vastaus sisältää json-tiedoston, joka sisältää pyydetyn access_token- tai virhetiedot.

Vastaustyyppi, jos onnistuu:

( "access_token" : "(pääsytunnus)" , "token_type" : "session" , "refresh_token" : "(refresh_token)" , "expires_in" : "(expires_in)" )

• access_token – käyttöoikeustunnus, jota käytetään luomaan pyyntö API:lle;
• token_type – päällä Tämä hetki vain istunto palautetaan;
• refresh_token – päivitystunnus, jota voidaan käyttää jatkossa yksinkertaistettuun valtuutusmenettelyyn. Voimassa 30 päivää;
• expires_in – pääsytunnuksen vanhenemisaika sekunneissa.

Vastauksen tyyppi virheen sattuessa

( "error" : "(virhe)" , "error_description" : "(virheen_kuvaus)" )

• error – virhekoodi;
• error_description – virheen kuvaus.

5. Refresh_tokenin käyttö Kun sinulla on refresh_token, voit saada access_tokenin yksinkertaistetulla menettelyllä tekemällä yhden POST-pyynnön URL-osoitteeseen:

https://api.ok.ru/oauth/token.do? refresh_token=(refresh_token)& Asiakastunnus=(asiakastunnus)& client_salaisuus=(asiakassalaisuus)& grant_type=(grant_type)

Vastausmuoto on samanlainen kuin vastaanottaa access_token, mutta ilman päivitystunnusta.

Mahdollisia virheitä

Virhe	Esiintymisen muunnelmia
Virheellinen pyyntö	*virheellinen koodi lähetetty (virheen kuvaus - virheellinen koodi) *koodi on vanhentunut (virheen kuvaus - vanhentunut koodi) * redirect_uri on eri kuin OAuth-vaiheessa välitetty (virheen kuvaus - Väärä redirect_uri)
invalid_client	*ei löytänyt määritettyä sovellusta (virheen kuvaus - Tuntematon asiakas)
unauthorized_client	* Salainen avain sovellus on virheellinen (virheen kuvaus - Virheelliset pyyntöparametrit)
pääsy evätty	* käyttäjä ei ole valtuuttanut sovellusta (esimerkiksi poisti sen asetukset, virheen kuvaus - Pääsy kielletty) * refesh_token on vanhentunut (virheen kuvaus - Päivitystunnus vanhentunut) * Käyttäjä pakotetaan uloskirjautumaan kaikista laitteista (cm. asetukset, virheen kuvaus - Kirjaudu ulos kaikista)
kelpaamaton_apuraha	* ei tunnistanut grant_type-parametria (virheen kuvaus - Virheellinen apurahatyyppi tai Virheelliset parametrit apurahatyypille)
virheellinen_tunnus	*käyttäjää ei voitu määrittää (virheen kuvaus - istunto vanhentunut) * refresh_token välitettiin väärin (virheen kuvaus - Virheellinen päivitystunnus / Virheellinen päivitystunnusrakenne / Virheellinen päivitystunnus, käyttäjä ei löydetty)

|

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 tili käyttäjä. OAuth 2 tarjoaa valtuutuksen verkkosovelluksille ja mobiililaitteille.

Tämä opas esittelee sinulle OAuth 2 -rooleja, valtuutustyyppejä, kuluja ja tapauksia käyttämällä OAuthia 2.

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 Palvelusovellusliittymä 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;
• URL-osoite soita takaisin tai redirect 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 tunnistetyyppi, joka on optimoitu palvelinpuolen sovelluksille lähde 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äytetään mobiilisovelluksia tai verkkosovelluksia, joissa asiakkaan salaisia ​​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ärjestelmä käyttäjä).

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

Asiakkaan tunnistetiedot

Tämän tyypin avulla sovellus voi muodostaa yhteyden oma tili palvelua. 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", < }