OAuth - OAuth - abcdef.wiki

OAuth ( O pen Auth orization ) on avoin standardi käyttöoikeuksien siirtämiselle , ja sitä käytetään yleisesti Internet -käyttäjien tapana myöntää verkkosivustoille tai sovelluksille pääsy tietoihinsa muilla verkkosivustoilla ilman, että heille annetaan salasanoja. Tätä mekanismia käyttävät yritykset, kuten Amazon , Google , Facebook , Microsoft ja Twitter , jotta käyttäjät voivat jakaa tietoja tileistään kolmansien osapuolten sovellusten tai verkkosivustojen kanssa.

Yleiskatsaus

Yleensä OAuth tarjoaa asiakkaille "suojatun valtuutetun pääsyn" palvelinresursseihin resurssin omistajan puolesta. Se määrittää prosessin, jonka avulla resurssien omistajat voivat valtuuttaa kolmannen osapuolen pääsyn palvelinresursseihinsa antamatta tunnistetietoja. Suunniteltu erityisesti toimimaan HTTP- protokollan kanssa, OAuth sallii pääsääntöisesti käyttöoikeustunnusten myöntämisen valtuutuspalvelimelta kolmannen osapuolen asiakkaille resurssin omistajan luvalla. Kolmas osapuoli käyttää sitten käyttöoikeustunnusta päästäkseen resurssipalvelimen isännöimiin suojattuihin resursseihin. Erityisesti OAuth 2.0 tarjoaa erityisiä valtuutusvirtoja verkkosovelluksille, työpöytäsovelluksille, matkapuhelimille ja älylaitteille .

Hypoteettinen valtuutuskulku, jossa kirjautumistiedot jaetaan kolmannen osapuolen sovelluksen kanssa. Tämä aiheuttaa monia tietoturvariskejä, jotka voidaan estää käyttämällä OAuth -valtuutusvirtoja.
Korkeatasoinen yleiskatsaus Oauth 2.0 -kulusta. Resurssin omistajan tunnistetietoja käytetään vain valtuutuspalvelimella, mutta ei asiakasohjelmassa (esim. Kolmannen osapuolen sovellus).

Historia

OAuth -logon on suunnitellut amerikkalainen bloggaaja Chris Messina

OAuth alkoi marraskuussa 2006, kun Blaine Cook kehitti Twitterin OpenID -toteutusta. Samaan aikaan Ma.gnolia tarvitsi ratkaisun, jotta OpenID -tunnuksella varustetut jäsenet voivat valtuuttaa Dashboard -widgetit käyttämään palveluitaan. Cook, Chris Messina ja Larry Halff Magnoliasta tapasivat David Recordonin keskustellakseen OpenID: n käyttämisestä Twitterin ja Magnolia -sovellusliittymien kanssa todennuksen delegoimiseksi. He päättivät, että API -käyttöoikeuksien siirtämiselle ei ollut avoimia standardeja.

OAuth -keskusteluryhmä perustettiin huhtikuussa 2007, jotta pieni toteuttajien ryhmä voisi kirjoittaa ehdotusluonnoksen avoimeksi pöytäkirjaksi. Googlen DeWitt Clinton sai tietää OAuth -hankkeesta ja ilmaisi kiinnostuksensa tukea työtä. Heinäkuussa 2007 tiimi laati alustavan eritelmän. Eran Hammer liittyi ja koordinoi monia OAuth -julkaisuja muodostaen muodollisemman määrittelyn. OAuth Core 1.0: n lopullinen luonnos julkaistiin 4. joulukuuta 2007.

Minneapolisissa marraskuussa 2008 pidetyssä 73. Internet Engineering Task Force (IETF) -kokouksessa pidettiin OAuth BoF -ryhmä, jossa keskusteltiin protokollan tuomisesta IETF: ään standardointityötä varten. Tapahtumaan osallistui runsaasti, ja OAuth -työryhmän viralliselle perustamiselle IETF: ssä annettiin laaja tuki.

OAuth 1.0 -protokolla julkaistiin nimellä RFC 5849, informaatiopyyntö kommentteihin , huhtikuussa 2010. 31. elokuuta 2010 jälkeen kaikkien kolmansien osapuolten Twitter -sovellusten on vaadittu käyttämään OAuthia.

OAuth 2.0 -kehys julkaistiin ottaen huomioon laajemmat IETF -yhteisöstä kerätyt lisäkäyttötapaukset ja laajennusvaatimukset. Vaikka se perustuu OAuth 1.0: n käyttöönottokokemukseen, OAuth 2.0 ei ole taaksepäin yhteensopiva OAuth 1.0: n kanssa. OAuth 2.0 julkaistiin RFC 6749 ja haltijan Token Käyttö RFC 6750, molemmat standardit seurata pyynnöt kommentit , lokakuussa 2012 mennessä.

OAuth 2.1 -valtuutuskehys on luonnosvaiheessa ja yhdistää toiminnot RFC-järjestelmiin OAuth 2.0, OAuth 2.0 natiivisovelluksille, Proof Key for Code Exchange, OAuth 2.0 selainpohjaisille sovelluksille, OAuth Security Best Current ja Bearer Token Usage.

Turvallisuusongelmat

OAuth 1.0

23. huhtikuuta 2009 ilmoitettiin 1.0 -protokollan istunnon kiinnitysvirheestä . Se vaikuttaa OAuth Core 1.0: n osion 6 OAuth-valtuutusvirtaan (joka tunnetaan myös nimellä "3-jalkainen OAuth"). OAuth Core -protokollan versio 1.0a on julkaistu tämän ongelman ratkaisemiseksi.

OAuth 2.0

Tammikuussa 2013 Internet Engineering Task Force julkaisi OAuth 2.0: n uhkamallin. Hahmoteltujen uhkien joukossa on yksi "Open Redirector"; alkuvuodesta 2014 Wang Jing kuvaili tämän varianttia nimellä "Covert Redirect".

OAuth 2.0 on analysoitu käyttämällä muodollista verkkoprotokolla -analyysiä. Tämä analyysi paljasti, että kokoonpanoissa, joissa on useita valtuutuspalvelimia, joista toinen käyttäytyy haitallisesti, asiakkaat voivat olla hämmentyneitä käyttämästään valtuutuspalvelimesta ja voivat välittää salaisuuksia haitalliselle valtuutuspalvelimelle (AS Mix-Up Attack). Tämä sai aikaan uuden parhaan käytännön Internet -luonnoksen luomisen, jonka tarkoituksena on määrittää uusi suojausstandardi OAuth 2.0: lle. Jos oletetaan, että AS Mix-Up Attack on korjattu, OAuth 2.0: n turvallisuus on osoitettu vahvoilla hyökkääjämalleilla käyttämällä muodollista analyysiä.

Yksi OAuth 2.0 -versio, jossa on lukuisia suojausvirheitä, on paljastettu.

Huhti- ja toukokuussa 2017 noin miljoona Gmailin käyttäjää (alle 0,1% käyttäjistä toukokuun 2017 aikana) joutui OAuth-pohjaisen tietojenkalasteluhyökkäyksen kohteeksi ja sai sähköpostin, jonka väitettiin olevan kollegalta, työnantajalta tai ystävältä, joka haluaa jakaa asiakirja Google Docsissa. Niitä, jotka napsauttivat sähköpostiviestissä olevaa linkkiä, kehotettiin kirjautumaan sisään ja antamaan mahdollisesti haitallisen kolmannen osapuolen "Google Apps" -ohjelman käyttää "sähköpostitiliään, yhteystietojaan ja online-asiakirjojaan". Google pysäytti tietojenkalasteluhyökkäyksen "noin tunnin" kuluessa ja neuvoi niitä, jotka olivat antaneet "Google Appsille" pääsyn sähköpostiinsa, peruuttamaan pääsyn ja vaihtamaan salasanansa.

OAuth 2.1 -luonnoksessa PKCE -laajennuksen käyttöä natiivisovelluksille on suositeltu kaikentyyppisille OAuth -asiakkaille, myös verkkosovelluksille ja muille luottamuksellisille asiakkaille, jotta vältetään haitalliset selainlaajennukset suorittamaan OAuth 2.0 -koodi -injektiohyökkäys.

Käyttää

Facebook : n Graph API tukee vain OAuth 2.0. Google tukee OAuth 2.0: aa suositeltavana valtuutusmekanismina kaikille sen sovellusliittymille . Microsoft tukee myös eri sovellusliittymien OAuth 2.0 -versiota ja sen Azure Active Directory -palvelua, jota käytetään suojaamaan monia Microsoftin ja kolmannen osapuolen sovellusliittymiä.

OAuthia voidaan käyttää valtuutusmekanismina suojattujen RSS / ATOM -syötteiden käyttämiseen. Todentamista edellyttävien RSS/ATOM -syötteiden käyttö on aina ollut ongelma. Esimerkiksi suojatun Google -sivuston RSS -syötettä ei olisi voitu käyttää Google Readerin avulla . Sen sijaan kolmijalkaisella OAuthilla olisi voitu valtuuttaa kyseinen RSS-asiakas käyttämään syötettä Google-sivustosta.

OAuth ja muut standardit

OAuth on palvelu, joka täydentää ja erottaa OpenID: n . OAuth ei liity OATH: hon , joka on todennuksen viitearkkitehtuuri , ei valtuutusstandardi. OAuth liittyy kuitenkin suoraan OpenID Connectiin (OIDC), koska OIDC on OAuth 2.0: n päälle rakennettu todennuskerros. OAuth ei myöskään liity XACML: ään , joka on valtuutuskäytäntöstandardi. OAuthia voidaan käyttää yhdessä XACML: n kanssa, jossa OAuthia käytetään omistajuuden suostumukseen ja käyttöoikeuksien siirtoon, kun taas XACML: ää käytetään valtuutuskäytäntöjen määrittämiseen (esim. Johtajat voivat tarkastella asiakirjoja omalla alueellaan).

OpenID vs. pseudo-todennus käyttämällä OAuthia

OAuth on valtuutusprotokolla eikä todennusprotokolla . OAuthin käyttöä yksinään todennusmenetelmänä voidaan kutsua pseudo-todennukseksi. Seuraavat kaaviot korostavat eroja OpenID: n (erityisesti todennusprotokollana) ja OAuthin käytön välillä valtuutusta varten.

Viestintävirta molemmissa prosesseissa on samanlainen:

(Ei kuvassa) Käyttäjä pyytää resurssin tai sivuston kirjautumista sovelluksesta.
Sivusto näkee, että käyttäjää ei ole todennettu. Se muotoilee pyynnön henkilöllisyyden tarjoajalle, koodaa sen ja lähettää sen käyttäjälle osana uudelleenohjaus -URL -osoitetta.
Käyttäjän selain pyytää identiteetin tarjoajan uudelleenohjaus -URL -osoitetta, mukaan lukien sovelluksen pyyntö
Tarvittaessa henkilöllisyyden tarjoaja todentaa käyttäjän (ehkä pyytämällä häneltä käyttäjänimeä ja salasanaa)
Kun henkilöllisyyden tarjoaja on vakuuttunut siitä, että käyttäjä on todennettu riittävästi, se käsittelee sovelluksen pyynnön, muotoilee vastauksen ja lähettää sen takaisin käyttäjälle yhdessä uudelleenohjausosoitteen kanssa takaisin sovellukseen.
Käyttäjän selain pyytää uudelleenohjaus -URL -osoitetta, joka palaa sovellukseen, mukaan lukien identiteetin tarjoajan vastaus
Sovellus purkaa identiteetin tarjoajan vastauksen ja jatkaa sen mukaisesti.
(Vain OAuth) Vastaus sisältää käyttöoikeustunnuksen, jonka avulla sovellus voi saada suoran pääsyn henkilöllisyyden tarjoajan palveluihin käyttäjän puolesta.

Ratkaiseva ero on siinä, että OpenID -todennuksen käyttötapauksessa identiteetin tarjoajan vastaus on henkilöllisyyden toteaminen; kun taas OAuth luvan käytön tapauksessa tunnistetietojen tarjoajan on myös API tarjoaja, ja vastaus tunnistetietojen tarjoajan on käyttötunnisteena joka voi hyväksyä hakemuksen jatkuva oikeus joihinkin identiteetin tarjoajan API, käyttäjän puolesta. Käyttöoikeustunnus toimii eräänlaisena "valet -avaimena", jonka sovellus voi sisällyttää pyyntöihinsä identiteettitoimittajalle, jotka osoittavat, että sillä on käyttäjän lupa käyttää kyseisiä sovellusliittymiä .

Koska henkilöllisyyden tarjoaja tyypillisesti (mutta ei aina) todentaa käyttäjän osana OAuth -käyttöoikeustunnuksen myöntämisprosessia, on houkuttelevaa nähdä onnistunut OAuth -käyttöoikeustunnuspyyntö itse todennusmenetelmänä. Koska OAuthia ei kuitenkaan suunniteltu tätä käyttötapaa silmällä pitäen, tämän oletuksen tekeminen voi johtaa merkittäviin tietoturva -aukkoihin.

OAuth ja XACML

XACML on käytäntöpohjainen, määritteisiin perustuva kulunvalvonnan valtuutuskehys. Se tarjoaa:

Kulunvalvonta arkkitehtuurin .
Käytäntökieli, jolla voidaan ilmaista laaja valikoima pääsynvalvontakäytäntöjä, mukaan lukien käytännöt, jotka voivat käyttää OAuthin kautta käsiteltyjä / määriteltyjä suostumuksia.
Pyyntö- / vastausjärjestelmä valtuutuspyyntöjen lähettämistä ja vastaanottamista varten.

XACML ja OAuth voidaan yhdistää tarjoamaan kattavampi lähestymistapa valtuutukseen. OAuth ei tarjoa käytäntökieltä, jolla määritellään käytönvalvontakäytännöt. XACML: ää voidaan käyttää sen käytännön kieleksi.

Jos OAuth keskittyy delegoituun käyttöoikeuteen (minä, käyttäjä, annan Twitter-käyttöoikeuden Facebook-seinälleni) ja henkilöllisyyskeskeiseen valtuutukseen, XACML käyttää määritteisiin perustuvaa lähestymistapaa, joka voi ottaa huomioon käyttäjän, toiminnon, resurssin ja asiayhteys (kuka, mitä, missä, milloin, miten). XACML: llä on mahdollista määritellä käytäntöjä, kuten

Johtajat voivat tarkastella asiakirjoja osastollaan
Johtajat voivat muokata omistamiaan asiakirjoja luonnostilassa

XACML tarjoaa tarkempaa kulunvalvontaa kuin OAuth. OAuthin rakeisuus rajoittuu kohdepalvelun paljastamiin karkeisiin toimintoihin (laajuuksiin). Tämän seurauksena on usein järkevää yhdistää OAuth ja XACML yhdessä, missä OAuth tarjoaa siirretyn käyttöoikeuden käytön ja suostumuksen hallinnan ja XACML tarjoaa sovelluksiin, prosesseihin ja tietoihin liittyvät valtuutuskäytännöt.

Lopuksi XACML voi toimia läpinäkyvästi useissa pinoissa ( sovellusliittymät , web-kertakirjaus, ESB: t, kotimaiset sovellukset, tietokannat ...). OAuth keskittyy yksinomaan HTTP-pohjaisiin sovelluksiin.

Kiista

Eran Hammer luopui OAuth 2.0 -projektin pääkirjailijan roolista, erosi IETF -työryhmästä ja poisti nimensä erittelystä heinäkuussa 2012. Hammer mainitsi lähtevänsä verkko- ja yrityskulttuurien välisen ristiriidan ja totesi, että IETF on yhteisö, joka koskee "yrityskäyttötapauksia" ja "ei kykene yksinkertaiseen". "Se, mitä nyt tarjotaan, on suunnitelma valtuutusprotokollalle", hän totesi, "se on yritystapa", joka tarjoaa "kokonaan uuden rajan konsultointipalvelujen ja integraatioratkaisujen myymiselle".

Vertaamalla OAuth 2.0: ta OAuth 1.0: een Hammer huomauttaa, että siitä on tullut "monimutkaisempi, vähemmän yhteentoimiva, vähemmän hyödyllinen, epätäydellisempi ja mikä tärkeintä, vähemmän turvallinen". Hän selittää, kuinka arkkitehtoniset muutokset 2.0 -sitoutumattomille tunnuksille asiakkailta poistivat kaikki allekirjoitukset ja salausprotokollatasolla ja lisäsivät vanhentuvia tunnuksia (koska tunnuksia ei voitu peruuttaa) ja vaikeuttivat samalla valtuutusten käsittelyä. Useita kohtia jätettiin määrittelemättömiksi tai rajoittamattomiksi eritelmissä, koska "tämän työryhmän luonteen mukaisesti mikään asia ei ole liian pieni jäämään jumiin tai jättämään avoimen jokaisen toteutuksen päätettäväksi".

David Recordon myöhemmin myös poistanut nimensä erittelyistä määrittelemättömistä syistä. Dick Hardt otti toimittajan roolin, ja kehys julkaistiin lokakuussa 2012.

Languages

In other projects

OAuth - OAuth

Sisällys