Oauth-sovellus. Apurahan tyyppi: Asiakkaan tunnistetiedot. Ero OAuthin ja OpenID:n välillä

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 asiakassovellusten kehitystä. Toiseksi huolimatta kolmen menetelmän (kutsutaan virrat) käyttöönotosta, jotka on ilmoitettu standardissa tunnuksen (ainutlaatuisen tunnisteen) hankkimiseksi valtuutusta varten: verkkosovelluksille, työpöytäasiakkaille ja mobiiliasiakkaille, 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 joissa loppukäyttäjällä 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 OpenID:hen millään tavalla.

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 kirjainten ja numeroiden merkkijono, 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 kyseiseltä ajalta.

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 tarkempia tietoja 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 kirjaimista ja numeroista, jotka ovat ainutlaatuisia ja vaikeasti arvattavia, ja avaimesta, joka suojaa tunnuksen luvattomalta käytöltä. 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 kulkua 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ääsytunnisteen 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

Tässä protokollan toimintatavassa palvelin tarjoaa pääsytunnuksen, kun asiakas on lähettänyt käyttäjänsä ja salasanansa, jotka valtuutuspalvelin on aiemmin asettanut (määrittely ei ilmoita 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 Eran Hammer, nykyinen OAuth 2.0 -standardin toimittaja, ilmoitti eroavansa kolmen vuoden työskentelyn jälkeen uuden standardin parissa ja pyysi, että hänen nimensä poistetaan spesifikaatioista. Hän on kertonut näkemyksistään verkkosivuillaan. Myöhemmin hän piti esityksen. .

Huomautuksia

Katso myös

Linkit

Wikimedia Foundation. 2010.

Tuloksena asiakassovellus AdWords-sovellusliittymän avulla pääset AdWords-tiliisi ilman osoitetta Sähköposti ja käyttäjän salasana.

OAuth2-tunnistetietojen luominen

Luo OAuth2-tunnistetiedot noudattamalla alla olevia ohjeita.

Sovellustyypin määrittäminen

Ensinnäkin sinun on määritettävä sovellustyyppi, jonka haluat luoda. AdWords API:ssa on kahdenlaisia ​​sovelluksia:

• asennettava sovellus(suositus);
• verkkosovellus.

Määritä alla olevan taulukon avulla haluttu tyyppi sovellukset.

Mitä valita	Tilanne
Asennettava sovellus(suositus)	Hallitset kaikkia AdWords-tilejä yhdellä hallinnoijan tilillä huipputaso. Oletko vasta aloittamassa vai haluatko päästä alkuun nopeasti? Sovelluksesi toimii yhdessä AdWords-tileissä, joissa on useita käyttäjiä.
verkkosovellus	Haluatko todentaa tarjotaksesi eri käyttäjiä erilaisia ​​käyttöoikeuksia AdWords-tilitietoihin. Sinun on luotava useita tunnistejoukkoja esimerkiksi hallitaksesi kolmannen osapuolen tilejä. Sovelluksesi vaatii URL-osoitteita soita takaisin, ei tueta asennetuissa sovelluksissa.

Huomio!Vaikka kehittäisit verkkosovellusta, voit silti valita asennettavan sovelluksen. Suurin ero on siinä, onko takaisinsoitto suoritettava tunnuksen antamisen jälkeen. Jos esimerkiksi käytät yhtä ylimmän tason hallinnoijan tiliä kaikkien AdWords-tilien hallintaan, asentamasi sovellus on rekisteröitävä, vaikka asiakassovellus olisikin käytettävissä Internetin kautta. Huomautus.käsitellään alla. Jos et vaadi palvelutilin toimivuutta, suosittelemme käyttämään asennuksen tai verkkosovelluksen valtuutusprosessia.

Asiakastunnuksen ja salaisen koodin luominen

Kun olet määrittänyt hakemuksesi tyypin, napsauta sopivaa välilehteä alla ja seuraa ohjeita tunnuksen luomiseksi ja salainen koodi asiakas.

Asennettava sovellus

1. Avata
2. Luo projekti Luoda.
3. Luo tunnistetiedot, ja sitten - OAuth-asiakastunnus.
4. Tallentaa
5. Luvussa Sovellustyyppi valitse Muut tyypit ja anna tarvittavat tiedot.
6. Klikkaus Luoda.
7. tunniste Ja Salainen avain

verkkosovellus

1. Avata
2. Valitse avattavasta projektit-valikosta Luo projekti, määritä sitten projektin nimi ja muuta sen tunnusta tarvittaessa ja napsauta sitten painiketta Luoda.
3. Valitse Tunnistetiedot-sivulla Luo tunnistetiedot, ja sitten - OAuth-asiakastunnus.
4. Sinua voidaan pyytää antamaan tuotteen nimi. Napsauta tässä tapauksessa Mukauta käyttöoikeuspyyntöikkunaa, anna pyydetyt tiedot ja napsauta Tallentaa palataksesi Tunnistetiedot-näyttöön.
5. Luvussa Sovellustyyppi valitse verkkosovellus. Määritä JavaScript-lähteet ja/tai uudelleenohjauksen URI:t noudattamalla ohjeita.
6. Klikkaus Luoda.
7. Kopioi näkyviin tulevalta sivulta tunniste Ja Salainen avain asiakas - tarvitset niitä asiakaskirjastoa määritettäessä.

Noudata alla olevia ohjeita määrittääksesi OAuth2-tunnistetietojen käyttö kielesi asiakaskirjaston kanssa.

Huomautus.Jos päätät olla käyttämättä jotakin asiakaskirjastoistamme, sinun on toteutettava prosessit itse tai itsellesi.

OAuth2 Playground

Vaihtoehtoinen vaihtoehto OAuth2-tunnistetietojen luomiseen on käyttää OAuth2 Playground. Yhdessä Google-sovellusliittymäkonsolin kanssa tämän järjestelmän avulla voit luoda OAuth2-tunnuksia itse.

OAuth2 Playground -järjestelmä on suunniteltu käyttäjille, jotka tarvitsevat pääsyn vain tileihin yksi hallinnoijan tilillä tai AdWords-käyttäjällä. Jos sinun on pyydettävä useiden käyttäjien tunnistetietoja, on parempi käyttää asiakaskirjastoja yllä kuvatulla tavalla.

asetukset

Varoitus.Käyttää OAuth2 Playground, sinun on luotava Asiakastunnus. Tämä ainoa sovellus, joka toimii OAuth2 Playgroundin kanssa. Lue lisää yllä olevasta osiosta.

Kuinka saada asiakastunnus ja salainen avain

1. Avata
2. Valitse avattavasta valikosta olemassa oleva projekti tai luo uusi.
3. Valitse Tunnistetiedot-sivulla Luo tunnistetiedot, ja sitten - OAuth-asiakastunnus.
4. Luvussa Sovellustyyppi valitse verkkosovellus.
5. Lisää osioon seuraava rivi: https://site/oauthplayground
6. Klikkaus Luoda.
7. Kirjoita se ylös tunniste Ja Salainen avain näkyviin tulevalla sivulla mainitut asiakkaat. Tarvitset niitä seuraavassa vaiheessa.

Kuinka luoda tunnuksia

Varoitus.Mistä Google-tili Olet kirjautunut selaimeesi. Se riippuu siitä, mihin AdWords-tileihin pääset luomillasi OAuth2-tunnistetiedoilla. Saattaa olla parempi suorittaa nämä vaiheet incognito-tilassa tai kirjautumatta Google-tilillesi. On todennäköistä, että sinun on käytettävä tunnistetietoja, jotka poikkeavat tilistä, jolla olit asiakastunnuksen ja salaisen avaimen vastaanottamisen yhteydessä.

Kuinka poistaa OAuth2 Playground asiakastunnuksesta

Koska sinulla jo on päivitä tunnus, sinun ei enää tarvitse käyttää OAuth2 Playgroundia ratkaistuna uudelleenohjaus-URI-osoitteena. Voit poistaa tämän järjestelmän luettelosta seuraavasti:

1. Mene .
2. Valitse projektisi avattavasta valikosta.
3. Valitse Tunnistetiedot-sivulla asiakastunnuksen nimi.
4. Poista https://site/oauthplayground kentältä Sallitut uudelleenohjaus-URI:t. Huomaa, että sinun on poistuttava vähintään yksi Uudelleenohjaus URI.
5. Klikkaus Tallentaa.

Joten sinulla on OAuth-kirjautumistietosi. Nyt voit suorittaa AdWords-kyselyt API ja käyttö vaadittavalle asiakaskirjastolle.

OAuth2-palvelutilit

Tässä osiossa kuvataan AdWords-sovellusliittymän käyttäminen palvelutilien avulla.

Palvelutili on tili, joka kuuluu sovellukselle, ei yksittäiselle loppukäyttäjälle. Palvelutilit tarjoavat vuorovaikutusta verkkosovelluksen ja Google-palvelun välillä. Sovelluksesi kutsuu API:ta palvelutilin puolesta ilman, että käyttäjiä otetaan suoraan mukaan.

AdWords-sovellusliittymä sallii palvelutilin käytön G Suite ‑verkkotunnuksissa.

Palvelutili toteuttaa OAuth2-prosessin, joka käyttäjän valtuutuksen sijaan käyttää avaintiedostoa, joka on vain sovelluksesi käytettävissä.

Palvelutilien käyttäminen tarjoaa kaksi merkittävää etua:

• Valtuutetaan sovelluksen käyttöoikeus kohteeseen Google API suoritetaan asennusvaiheessa. Näin vältytään käyttäjän toimista tai välimuistiin tallentamisesta muissa OAuth2-virroissa.
• Tarvittaessa muiden käyttäjien esiintyminen sovelluksessa tapahtuu osana OAuth2-hyväksyntäprosessia.

Huomautus. Jos et käytä verkkotunnuskohtaisia ​​ominaisuuksia, kuten toisena henkilönä esiintyminen, palvelutilien sijaan on erittäin suositeltavaa käyttää prosessia . Osana OAuth2-asennus- ja verkkosovellusprosesseja käyttäjän osallistumista vaaditaan vain kerran – tilin käyttöoikeuden myöntämisen yhteydessä.

Vaihtoehto palvelutileille

Palvelutilejä käytetään laajasti tarjoamaan ohjelmiston pääsy API:lle OAuth2-protokollan kautta ilman käyttäjän toimia.

Tällaisten tilien määrittäminen toimimaan AdWords API:n kanssa ei kuitenkaan ole helppoa. Yksinkertaisempi vaihtoehto on jatkuvalla päivitystunnuksella. Tämän lähestymistavan avulla sovellus voi pyytää uusia käyttöoikeuksia milloin tahansa.

Osana tätä prosessia sinun on määritettävä sovelluksen valtuutus asiakaskirjaston kautta yllä kuvatulla tavalla. Tämä täytyy tehdä vain kerran, koska tunnukset vanhenevat Googlen päivitykset OAuth2 on rajoittamaton.

Vaatimukset

• Omistamasi G Suite ‑verkkotunnus, kuten mydomain.com tai mybusiness.com.
• AdWords API -kehittäjätunnus ja mieluiten testitili.
• käytettävälle kielelle.

Käyttöoikeuden määrittäminen asiakastilille

Ensin sinun on luotava palvelutilin avain Google-sovellusliittymäkonsolissa.

1. Kirjaudu G Suite ‑tilillesi ja avaa .
2. Valitse avattavasta projektit-valikosta Luo projekti, anna sitten tarvittavat tiedot ja napsauta painiketta Luoda. Uusi projekti näkyy aktiivisessa luettelossa.
3. Vasemmalla olevassa valikossa yläkulma valitse IAM ja hallinto, ja sitten - Palvelutilit vasemmalla olevassa valikossa.
4. Klikkaus Luo palvelutili sivun yläreunassa.
5. Anna palvelutilin nimi.
6. Valitse ruutu Luo uusi yksityinen avain ja valitse JSON-avaintyyppi.
7. Valitse ruutu Ota tietojen käyttöoikeuden delegointi käyttöön G Suite ‑verkkotunnuksessasi ja anna tuotteen nimi käyttöoikeuspyyntöikkunalle.
8. Klikkaus Luoda. JSON-avaintiedoston lataus alkaa. Tallenna tiedosto turvalliseen paikkaan, johon vain sinulla on pääsy.
9. Sivulla Palvelutilit uusi palvelutili tulee näkyviin.

Huomautus. Koska käyttäjän toisena henkilönä esiintymistä voidaan hallita vain verkkotunnustasolla, jotta voit käyttää palvelutilejä ja hyväksymisprosessia Googlen palvelut OAuth2, tarvitset oman verkkotunnuksesi, joka on rekisteröity G Suiteen. Kaikki verkkotunnuksen käyttäjät, jotka käyttävät palvelutiliä, jolla on asianmukaiset käyttöoikeudet, voivat esiintyä minkä tahansa toimialueen käyttäjänä.

Turvallisuusongelmat

Koska G Suitea hallitaan verkkotunnustasolla, sinun on suojattava turvallisesti avaintiedosto, jonka avulla valtuutetut tilit voivat käyttää sitä Googlen palvelut. Tämä on erityisen tärkeää, koska tarjoamme palvelutilille mahdollisuuden esiintyä kenenä tahansa verkkotunnuksen käyttäjänä.

Lisäksi on suositeltavaa, että kullakin palvelutilillä on pääsy vain yhteen Google-sovellusliittymään. Kenttää käytetään tähän tarkoitukseen soveltamisalaan, joka on kuvattu seuraavassa osassa. Sellainen ehkäisevä toimenpide voit rajoittaa luvattomalle pääsylle avoinna olevan tiedon määrää, jos avaintiedosto vaarantuu.

Kuinka tarjota toisena henkilönä esiintymisen ominaisuuksia

Voit myöntää palvelutilille toisena henkilönä esiintymisen ominaisuudet seuraavasti:

Voit nyt käyttää AdWords-tiliäsi käyttämällä palvelutiliäsi osana OAuth2-hyväksyntäprosessia.

Asiakaskirjaston määrittäminen

Valitse kieli nähdäksesi ohjeet asiakaskirjaston määrittämiseen.

Huomautus.Jos päätät olla käyttämättä jotakin asiakaskirjastoistamme, sinun on toteutettava prosessi itse.

OAuth2-pyyntöjen optimointi

Jos sovelluksesi ei käytä tunnistetietojen jakamista, se voi lisätä merkittävästi Googlelle lähetettyjen pyyntöjen määrää. Tämän seurauksena palvelimemme voivat asettaa rajoituksia tällaiselle sovellukselle, mikä hidastaa sen toiminnan nopeutta.

Tässä osiossa kuvataan, kuinka OAuth2-tunnistetietojen hallinta optimoidaan, jotta sovelluksesi toimii tehokkaammin AdWords-sovellusliittymän kanssa.

Huomio!Termin alla valtakirjat Tämä viittaa koko joukkoon OAuth2-tunnisteattribuutteja, mukaan lukien käyttöoikeustunnus ja sen viimeinen voimassaolopäivä.

Tunnistetietojen jakelustrategiat

Tunnistetietojen jakaminen API-pyyntöjen kesken parantaa suorituskykyä ja myös välttää liiallinen kuormitus ja rajoitusten rikkomisesta johtuvia virheitä.

Tunnistetietojen jakelustrategia riippuu sovelluksen suunnittelusta.

Monisäikeisissä sovelluksissa sinun on käytettävä samoja tunnistetietoja jokaisen säikeen istunnossa.

Moniprosessissa ja hajautetut sovellukset On tarpeen ottaa käyttöön jokin infrastruktuuri valtuustietojen välittämiseksi prosessien välillä. Lisäksi sinun on varmistettava, että langat eivät tukkeudu ja kilpailuolosuhteita ei esiinny.

Sovelluksessa, joka on sekä moniprosessi/hajautunut että monisäikeinen, jokaisen prosessin on yhdistettävä molemmat strategiat.

Seuraavat ovat strategioita yksittäisen AdWords-tilin, kuten hierarkian ylimmän tason hallinnoijan tilin, todentamiseksi.

Sitten kuvataan, kuinka näitä strategioita voidaan mukauttaa .

Monisäikeiset sovellukset

Monisäikeisissä sovelluksissa valtuustietojen on oltava saatavilla eri säikeille. Tunnistetietojen päivitykset on tehtävä synkronisesti kilpailuolosuhteiden välttämiseksi.

Tämä kaavio näyttää säikeet, jotka välittävät pyynnöt AdWords API:lle suorituksen aikana. Käytetään jaettua istuntojen (käyttäjien) poolia. Huomaa, että jokaisessa istunnossa on käytettävä samaa tunnistetietoobjektia. Vastauksena jokaiseen API-pyyntöön säie vastaanottaa vastaavan istunnon (käyttäjän). Jos pääsytunnus on päivitettävä, se on tehtävä synkronisesti kilpailutilanteen välttämiseksi. Toisin sanoen valtuustietoobjektin on oltava säikeen turvallinen.

Asiakaskirjastojen avulla valtuustietojen välittäminen säikeiden välillä on helppoa. Jokaisella asiakaskirjastolla on istunto- (tai käyttäjä-)objekti valtuustiedoilla, joita se käyttää uudelleen koko ajan elinkaari. Jos haluat käyttää tunnistetietoja istuntojen välillä, sinun on otettava ne käyttöön jokaisen istunnon luomisen yhteydessä. Kaikissa asiakaskirjastoissa valtuustiedot ovat säikeen suojattu objekti, joka päivitetään synkronisesti, kun käyttöoikeustunnus vanhenee.

Esimerkiksi Java-asiakaskirjastossa luot yksittäisen Credential-luokan ja käytät sitä kaikissa istunnoissa.

Moniprosessi- ja hajautetut sovellukset

Moniprosessisissa ja hajautetuissa sovelluksissa tunnistetietojen jakelun on oltava jatkuvaa. Jotta vältytään kilpailutilanteelta, jossa useat palvelimet yrittävät päivittää tunnistetietoja samanaikaisesti (joka aiheuttaa liiallisia päivityspyyntöjä), on suositeltavaa pakottaa päivitys ja toimittaa päivitetyt tunnistetiedot kaikille prosesseille ja palvelimille.

Esimerkiksi yksittäinen tehtävä tai palvelu saattaa ajoittain päivittää tunnistetiedot ja työntää ne tietosäilöön, jossa eri palvelimet käyttävät niitä.

Kaavio näyttää valtuustietojen säännöllisen päivityksen ja niiden ominaisuuksien tallentamisen tietovarastoon. Kaikki palvelimet saavat sitten kirjautumistiedot ennen pyynnön tekemistä API:lle.

Päivitä tehtävä

Päivitystehtävä päivittää ajoittain tunnistetiedot ja lähettää ne tietovarastoon. Tämän tehtävän ei pitäisi odottaa nykyisten valtuustietojen vanhenemista, koska tämä aiheuttaa sen, että sovellus ei toimi jonkin aikaa kelvollisten valtuustietojen puutteen vuoksi.

Paras vaihtoehto on pakottaa säännöllinen päivitys, joka korvaa tietovaraston tunnistetiedot uusilla joka kerta. Päivitystehtävä tulee suorittaa hyvissä ajoin ennen nykyisten valtuustietojen vanhenemista, jotta aikaa jää riittävästi tilapäisen virheen sattuessa. Voit aloittaa päivittämällä 15 minuutin välein.

Huomautus.Jos valtuustietojen käyttöoikeus vanhenee API-pyynnön käsittelyn aikana, pyyntö suoritetaan edelleen. Jos esimerkiksi luot pitkään jatkuvan kyselyn ja sinulla on alle minuutti aikaa käyttää, tulokset palautetaan silti.

Tietovarasto

Tietovarastoa käytetään valtuustietojen antamiseen erilaisia ​​prosesseja ja palvelimia.

Voit tehdä tämän käyttämällä olemassa olevaa tietovarastoa tai luoda erikoistuneen varaston, jonka kautta palvelimet vastaanottavat tunnistetiedot. Mahdollisia ratkaisuja ovat välimuistipalvelimet (kuten Memcached tai Infinispan) ja NoSQL-tietovarastot (kuten MongoDB).

Tietovaraston päätarkoitus on tarjota luotettava käyttöliittymä kaikille APIa käyttäville palvelimille. Sen toiminta on optimoitava nopeaa lukemista tiedot: palvelimet ja prosessit lukevat valtuustiedot useammin kuin ne päivitetään.

Muista pitää kirjautumistietosi turvassa.

Kun tallennat tunnistetietoja, sinun on tallennettava expiry_time-ominaisuus ( nykyinen aika+ expires_in) ja refresh_token sekä access_token-ominaisuuden. Ominaisuus expiry_time (token expiration date) lasketaan seuraavalla kaavalla: access_token päivityspyynnön aika + expires_in time (tunnisteen vanhentumispäivämäärä).

Palvelin allas

Jokainen poolin palvelin hankkii viimeisimmät valtuustiedot tietovarastosta ennen pyynnön lähettämistä. Niin kauan kuin päivitystehtävä suoritetaan onnistuneesti, valtuustiedot ovat voimassa. Jos päivitystehtävä tai tietovarasto kuitenkin epäonnistuu, on oltava varamekanismi.

Jos palvelin tai prosessi ei pysty saamaan tunnistetietoja tietovarastosta tai jos valtuustiedot ovat vanhentuneet, palvelimen on päivitettävä tunnistetietonsa, jotta sovellus voi jatkaa työskentelyä API:n kanssa, kunnes ongelma on ratkaistu.

Monisäikeisissä prosesseissa sinun on käytettävä samaa strategiaa valtuustietojen jakamiseen säikeiden kesken.

Usean tilin todennus

AdWordsin hallinnoijan tilille luotuja kirjautumistietoja voidaan käyttää kaikkien alatason tilien käyttämiseen. Käyttäjien, joilla on yksi hallinnoijan tili, tarvitsee yleensä vain luoda kirjautumistiedot ylimmän tason hallinnoijan tilille valtuuttaakseen sovelluksen kaikille alisteisille AdWords-tileille.

Muissa tapauksissa sovelluksella on oltava pääsy AdWords-tileihin, jotka eivät liity toisiinsa hallinnoijan tilien hierarkiassa. Tässä tilanteessa sinun on luotava ja ylläpidettävä useita valtuustietoja eri tilejä, esimerkiksi jokaiselle AdWords-asiakastilille, johon sinulla on käyttöoikeus, tai jokaiselle ylimmän tason hallinnoijan tilille itsenäisissä hierarkioissa.

Voit noudattaa näitä strategioita molemmissa sovelluksissa pienin muutoksin. Käyttämällä jaettu tallennustila Tunnistetiedot on indeksoitava tilin tunnuksella customerId, jotta varmistetaan, että tunnistetiedot on liitetty vaadittuun tiliin. Lisäksi päivitystehtävän on päivitettävä ne ajoissa. Kun olet yhdistänyt uuden tilin, saatat joutua käynnistämään sen.

Lopuksi monisäikeisissä sovelluksissa sinun on jaettava valtuustietoobjekti vain niiden säikeiden kesken, jotka ovat käynnissä tilillä, johon se on liitetty.

Miten OAuth2 toimii

Huomautus. AdWords-sovellusliittymä ei vielä tue samanaikaista sisäänkirjautumista tietojen käyttöpyynnön (hybridisuunnittelu) tai verkkotunnustason valtuuksien delegoinnin (2LO) kautta.

Laajuus

Käyttöoikeustunnus voi tarjota eriasteisia pääsyä tietoihin. Muuttujan laajuus -parametri määrittää resurssien ja toimintojen joukon, joihin tunnuksella on pääsy. Kun pyydät käyttöoikeustunnusta, sovelluksesi lähettää yhden tai useamman arvon laajuusparametrille.

Alla on AdWords-sovellusliittymän nykyinen ja vanha laajuus.

Offline-käyttö

AdWords-sovellusliittymää käyttävä asiakassovellus pyytää yleensä offline-käyttöä. Näin voi tapahtua, jos sovelluksesi on suoritettava erätöitä, kun käyttäjä selaa sivustoasi ilman Internet-yhteyttä.

Asennetut sovellukset käyttävät oletusarvoisesti offline-käyttöä.

HTTP-pyynnön otsikko

Jokaisen AdWords API -palvelimelle osoitetun pyynnön HTTP-otsikon on sisällettävä seuraava lomake:

Valtuutus: siirtotie THE_ACCESS_TOKEN

LÄHETYS ... HTTP/1.1 Isäntä: ... Valtuutus: Siirtotie 1/fFAGRNJru1FTz70BzhT3Zg Sisältötyyppi: text/xml;charset=UTF-8 Sisältö-pituus: ... …

Käytä ja päivitä tunnuksia

Useimmissa tapauksissa päivitystunnus on tallennettava turvallinen paikka, koska sitä voidaan tarvita tulevaisuudessa. Lisätietoja käyttöoikeuksien pyytämisestä ja päivitystunnuksista on seuraavissa oppaissa:

Kun käyttöoikeustunnus vanhenee

Käyttöoikeustunnuksella on viimeinen voimassaolopäivä, joka riippuu expires_in -arvon arvosta. Vanhentunut käyttöoikeustunnus voidaan päivittää päivitystunnuksella, mutta asiakaskirjastomme tekevät tämän automaattisesti.

Ellei toisin mainita, tämän sivun sisältö on lisensoitu Creative Commons Attribution 3.0 -lisenssillä ja koodinäytteet Apache 2.0 -lisenssillä. Katso lisätietoja meidän. Java on Oraclen ja/tai sen tytäryhtiöiden rekisteröity tavaramerkki.

Päivitetty 24. syyskuuta 2018

|

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

Tässä oppaassa esitellään OAuth 2:n rooleja, valtuutustyyppejä, kuluja ja käyttötapauksia OAuth 2:lle.

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 vahvistaa käyttäjän tunnistetiedot ja myöntää 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 palvelusivuston 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ä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 sisään 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 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 tilin käyttämiseen 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 sai päivitystunnuksen käyttöoikeustunnuksen kanssa, se voi nyt pyytää sitä uuden käyttöoikeustunnuksen valtuutuspalvelimelta.

Olet nyt perehtynyt OAuth 2:n perusteisiin.

Tunnisteet: ,

OAuth 2 on valtuutuskehys, joka sallii sovellusten rajoitettu pääsy käyttäjätileille 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 OAuth 2:n avulla.

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.

Kehittäjän näkökulmasta API-sovellukset Palvelu 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ä lupa käyttää resurssipalvelinta.
2. Jos käyttäjä hyväksyy pyynnön, sovellus saa valtuutuksen.
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 katsomme Erilaisia ​​tyyppejä valtuutusoikeudet.

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 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 saatavilla 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öoikeustunnuksen 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ä eri tyyppiä, 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: käytetään luotettavia sovelluksia, esimerkiksi sovellukset, jotka ovat osa itse palvelua.
• 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ötunnuksen

• ("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 välitettäväksi sovellukselle. Tämä puolestaan ​​asettaa tunnuksen käyttäjän ja muiden sovellusten saataville 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

Implisiittisen valtuutuslupatyypin kanssa käyttäjä saa linkin, joka pyytää sovellusliittymältä tunnuksen. Tämä linkki näyttää melkein samalta kuin edellisen menetelmän linkki (valtuutuskoodilla), paitsi että se kysyy 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än tyyppistä lupaa tulisi käyttää vain, jos käyttäjä luottaa sovellukseen (esimerkiksi se on osa itse palvelua tai käyttöjärjestelmä käyttäjä).

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

Asiakastunnistetietojen valtuutusoikeustyyppi sallii sovelluksen käyttää omaa palvelutiliään. 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ää OAuth 2 -tarkastelumme. Sinulla on nyt perusymmärrys OAuth 2:n toiminnasta sekä milloin ja miten sitä käytetään olemassa olevia tyyppejä valtuutusoikeudet.

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

Vaihe 1. Sivuston rekisteröinti

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

• Yksityinen avain
• Salainen avain

Olemme kiinnostuneita vain 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.

Mukavuussyistä erotamme logiikka linkin luomiseksi koodin vastaanottamiseksi ja sen käsittelemiseksi:
example.com/login.php - luo linkki koodin saamiseksi (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-koodiparametrilla.
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:n on vastattava täsmälleen vaiheessa 2 käyttämäämme.

Pyyntö tunnuksen saamiseksi 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" => "valtuutuskoodi", "koodi" => $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). Muuten, tietääkö kukaan 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 lasketaan md5-algoritmilla aakkosjärjestykseen järjestetystä parametrijonosta, joka on välitetty API:lle 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. Koko 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.