Oauth palvelu. Tästä hauskuus alkaa. Asiakkaan tunnistetietojen käsittely

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", < }

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

Ensin 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 takaisinsoitto-URL-osoitteita, joita asennetut sovellukset eivät tue.

Huomio!Vaikka kehittäisit verkkosovellusta, voit silti valita asennettavan sovelluksen. Suurin ero on siinä, otetaanko käyttöön soita takaisin 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 valtuutusprosessia asennettavalle tai verkkosovellukselle.

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 - Tunniste OAuth-asiakas .
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 tunnus 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ää osiossa 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:na. 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äytä vaadittua asiakaskirjastoa varten.

OAuth2-palvelutilit

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

Palvelutili on sovellukseen kuuluva tili, ei erillinen tili. loppukäyttäjä. 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ä erikoistoiminnot verkkotunnus, kuten toisena henkilönä esiintyminen, palvelutilien sijaan on erittäin suositeltavaa käyttää prosessia . OAuth2-asennettavat ja verkkosovellusprosessit edellyttävät käyttäjän osallistumista 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, johon valtuutetut tilit pääsevät 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 laajuus, 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 OAuth2-tunnistetietojen hallinnan optimointi, 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 valtuustietojen 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 säännöllinen pakotettu päivitys, jossa tietovaraston tunnistetiedot korvataan 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 tunnistetietojen 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. Kuten mahdolliset ratkaisut voit käyttää välimuistipalvelimia (esimerkiksi Memcached tai Infinispan) ja NoSQL-tietovarastoja (esimerkiksi 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 uusimmat 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

AdWords-hallinnoijan tilillesi luomillasi kirjautumistiedoilla voit käyttää kaikkia alatason tilejä. 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 tilitunnuksella 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 valtuutuskehys, joka sallii sovellusten rajoitettu pääsy käyttäjätileille HTTP-palvelut esimerkiksi Facebookissa, GitHubissa ja DigitalOceanissa. Se toimii periaatteella delegoida käyttäjän todennus palvelulle, jossa käyttäjätili sijaitsee, mikä mahdollistaa kolmannen osapuolen sovellus päästä käyttäjätiliin. 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 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 todelliset vaiheet voivat 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 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 saatavilla oleva merkkijono, jota käytetään Palvelusovellusliittymä sovelluksen tunnistamiseen, ja sitä 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ä lähde sovellukset 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 ohjaa 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 välitettäväksi sovellukselle. 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

Implisiittisen valtuutuslupatyypin kanssa käyttäjä saa linkin, joka pyytää sovellusliittymältä tunnuksen. 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 estämään sen pääsyn käyttäjätiliin. Alla on esimerkki tällaisesta dialogista:

Vaihe 3: Käyttäjäagentti saa 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 hakukomentosarjan ja välittää sitten haetun 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-kysely 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ää tätä tunnusta päästäkseen käyttäjätiliin palvelun API:n kautta määritetyillä käyttörajoituksilla, 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.

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)& laajuus=(laajuus)& vastauksen_tyyppi=((vastauksen_tyyppi))& redirect_uri=(uudelleenohjausUri)& layout=(asettelu)& osavaltio=(osavaltio)

Nimi	Edellytetään	Kuvaus
Asiakastunnus	Joo	Sovellustunnus
laajuus	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. '?'-merkin (kysely) jälkeistä osaa URI:sta ei oteta huomioon tarkastuksessa, 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ätunnuksensa ja salasanansa, jos hän ei ole tehnyt niin aiemmin. 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 vastaanottaminen access_token, mutta ilman refresh_token.

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	*sovelluksen salainen avain 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äivitystunniste / Virheellinen päivitystunnus, käyttäjää ei löydy)

VKontaktessa on monia tapoja levittää haitallista roskapostia. Mutta tuholaiset eivät nuku, heidän päänsä tulee yhä enemmän mielenkiintoisia ideoita. Ja se osoittautui erittäin hyödylliseksi. Huijarit ovat oppineet käyttämään sitä haitallisten sivustojen varoitussivun ohittamiseen.

Ja kaikki alkoi, kun eräänä päivänä seinälleni ilmestyi seuraava viesti:


Uteliaisuudesta seurasin linkkiä ja päädyin toiselle tietojenkalastelusivustolle. Mutta itse linkki vaikutti minusta oudolta, se näytti (puolet ASCII-merkeistä):
vkontakte.ru/away.php? to=http%3A%2F%2FApi.vKontakte.Ru%2F%2Fo%2561u%2574%…

Tästä se hauskuus alkaa...

Katsotaanpa toista linkkiä osissa:

Mitä kukin parametri tarkoittaa:

• client_id - valtuutuksen vaativan sovelluksen tunnus;
• redirect_uri - osoite, johon pääsytunnus lähetetään (uudelleenohjauksen kautta);
• näyttö - valtuutusikkunan tyyppi (sivu, ponnahdusikkuna, kosketus ja wap).

Itse asiassa redirect_uri sisälsi tietojenkalastelusivuston osoitteen. Koska näyttöparametrissa oli virhe (se sisälsi roskaa "?390852"), valtuutusikkunaa ei näkynyt, vaan se ohjattiin välittömästi tietojenkalastelusivustolle seuraavilla parametreilla: error=invalid_request&error_description=Invalid+display+passed

Tämä on haitallisten VKontakte-sivustojen mustan listan ohittaminen. Näkyviin tulee vain ilmoitus siirtymisestä api.vk.com-sivustoon. Ja siirtymisen seurauksena siirrymme suoraan mustalla listalla olevalle tietojenkalastelusivustolle. Kun seuraat linkkiä vkontakte.ru/away.php?to=vgostivk.dyndns**:

Kuten kävi ilmi, lupaa vaativa sovellus roikkui hakkeroidun käyttäjän päällä:

Ja itse phishing-sivusto oli suunniteltu varsin mielenkiintoisesti. Suunnittelu oli tuttuun tapaan kontaktimainen ja pyydettiin kirjautumaan sisään. Kirjauduin sisään satunnaisella sähköpostilla ja salasanalla, ja nielin väärennöksen hienosti. Se, mitä tapahtui seuraavaksi, oli vielä mielenkiintoisempaa, uutiset "Pavel Durovista" ilmestyivät pääsivulle:

Kun olet napsauttanut "Luo" -painiketta henkilökohtainen laskuri", jota seurasi upea edistymispalkki. Sitten sinua pyydettiin ilmoittamaan numerosi ja lähettämään tekstiviesti:

Teoriassa onnistuneen "aktivoinnin" jälkeen sen olisi pitänyt ohjata uudelleen activ.php-sivulle, mutta en päässyt sinne. Otteita tietojenkalastelusivuston JS-skripteistä:

...
jos (vaatimuksen tila == 200) (
// jos tila on 200 (OK) - anna vastaus käyttäjälle
if (req.responseText == "ok" ) (
//statusElem.innerHTML = "Kaikki surina!";
get_activation();
}
if (req.responseText == "ei" ) (statusElem.innerHTML = "Virheellinen aktivointikoodi";}
//statusElem.innerHTML = "Palvelimen vastaus: "+req.responseText;
...
funktio get_activation() (
document .location="activ.php" ;
}

* Tämä lähdekoodi korostettiin Source Code Highlighterilla.

Bottom line: Huijarit käyttävät OAuth 2.0:aa varoitusten ohittamiseen, salasanan hankkimiseen ja käyttäjän sähköposti, ja he yrittävät myös pettää sms:n lähettäminen(todennäköisimmin tilausjärjestelmällä).