Mikä on OAuth? Määritelmä ja miten se toimii

Olemme puhuneet salasanojen luovuttamisesta ja siitä, miten sitä ei pitäisi koskaan tehdä. Kun verkkosivusto haluaa käyttää toisen osapuolen palveluita – kuten Bitlyn lähettämistä Twitter-virtaasi – sen sijaan, että se pyytäisi sinua jakamaan salasanasi, sen tulisi käyttää sen sijaan protokollaa nimeltä OAuth.

On tärkeää ymmärtää, miten ohjelma, verkkosivusto tai sovellus saattaa todentaa sinut käyttäjänä – onko niillä oikeat oikeudet? Oletko antanut niille jonkinlaisen tavan todentaa, kuka olet – ja käyttää tietoja puolestasi? OAuth auttaa virtaviivaistamaan tätä prosessia: mutta automaationkin avulla kannattaa aina olla tietoinen siitä, miten henkilö tai yritys käyttää (tai tallentaa) tietojasi.

Mikä on OAuth?

OAuth on avoimen standardin mukainen valtuutusprotokolla tai -puitteisto, joka tarjoaa sovelluksille mahdollisuuden ”turvattuun nimettyyn käyttöön”. Voit esimerkiksi kertoa Facebookille, että ESPN.com saa käyttää profiiliasi tai julkaista päivityksiä aikajanallesi ilman, että sinun tarvitsee antaa ESPN:lle Facebook-salasanaasi. Tämä minimoi riskin merkittävällä tavalla: Jos ESPN:n tietomurto tapahtuu, Facebook-salasanasi pysyy turvassa.

OAuth ei jaa salasanatietoja, vaan sen sijaan se käyttää valtuutustunnisteita identiteetin todistamiseen kuluttajien ja palveluntarjoajien välillä. OAuth on todennusprotokolla, jonka avulla voit hyväksyä yhden sovelluksen, joka on vuorovaikutuksessa toisen sovelluksen kanssa puolestasi, luovuttamatta salasanaasi.

SAML vs. OAuth

SAML (Security Assertion Markup Language, Security Assertion Markup Language) on vaihtoehtoinen federoitu todennusstandardi, jota monissa yrityksissä käytetään SSO:ssa (Single-Sign On). SAML:n avulla yritykset voivat valvoa, kenellä on pääsy yrityksen resursseihin.

SAML:n ja OAuthin välillä on monia eroja. SAML käyttää XML:ää viestien välittämiseen, ja OAuth käyttää JSONia. OAuth tarjoaa yksinkertaisemman mobiilikokemuksen, kun taas SAML on suunnattu yritysten turvallisuuteen. Tämä viimeinen kohta on keskeinen erottava tekijä: OAuth käyttää laajasti API-kutsuja, minkä vuoksi mobiilisovellukset, nykyaikaiset verkkosovellukset, pelikonsolit ja esineiden internetin (IoT) laitteet pitävät OAuthia käyttäjälle parempana kokemuksena. SAML taas pudottaa selaimeen istuntoevästeen, jonka avulla käyttäjä pääsee tietyille verkkosivuille – tämä sopii hyvin lyhytaikaisiin työpäiviin, mutta ei niin hyvin, kun on kirjauduttava termostaattiin joka päivä.

OAuth Esimerkkejä

Yksinkertaisin esimerkki OAuthista toiminnassa on, että yksi verkkosivusto sanoo: ”Hei, haluatko kirjautua verkkosivuillemme toisten verkkosivujen sisäänkirjautumisluvuilla?”. Tässä skenaariossa ensimmäinen verkkosivusto – kutsuttakoon tätä verkkosivustoa kuluttajaksi – haluaa tietää vain sen, että käyttäjä on sama käyttäjä molemmilla verkkosivustoilla ja että hän on kirjautunut onnistuneesti palveluntarjoajalle – joka on sivusto, jolle käyttäjä alun perin kirjautui, ei kuluttaja.

Facebook-sovellukset ovat hyvä OAuth-käytön esimerkki. Sanotaan, että käytät sovellusta Facebookissa, ja se pyytää sinua jakamaan profiilisi ja kuvasi. Facebook on tässä tapauksessa palveluntarjoaja: sillä on kirjautumistietosi ja kuvasi. Sovellus on kuluttaja, ja käyttäjänä haluat käyttää sovellusta tekemään jotain kuvillesi. Annoit nimenomaan tälle sovellukselle pääsyn kuviin, joita OAuth hallinnoi taustalla.

Älykkään kotisi laitteet – leivänpaahdin, termostaatti, turvajärjestelmä jne. – käyttävät luultavasti jonkinlaisia kirjautumistietoja synkronoidakseen keskenään ja antaakseen sinulle mahdollisuuden hallinnoida niitä selaimesta tai asiakaslaitteesta. Nämä laitteet käyttävät sitä, mitä OAuth kutsuu luottamukselliseksi valtuutukseksi. Se tarkoittaa, että ne pitävät hallussaan salaiset avaintiedot, jotta sinun ei tarvitse kirjautua sisään kerta toisensa jälkeen.

OAuth Explained

OAuthissa on kyse valtuutuksesta eikä todennuksesta. Auktorisointi on luvan pyytämistä asioiden tekemiseen. Autentikointi on sen todistamista, että olet oikea henkilö, koska tiedät asioita. OAuth ei välitä todennustietoja kuluttajien ja palveluntarjoajien välillä – vaan toimii sen sijaan eräänlaisena valtuutusmerkkinä.

Yleinen vertaus, jota olen nähnyt käytettävän OAuthia tutkiessani, on auton pysäköintiavain. Palvelija-avaimen avulla palvelija voi käynnistää ja liikuttaa autoa, mutta se ei anna hänelle pääsyä takakonttiin tai hansikaslokeroon.


OAuth-token on kuin tuo palvelija-avain. Käyttäjänä pääset kertomaan kuluttajille, mitä he voivat käyttää ja mitä he eivät voi käyttää kullakin palveluntarjoajalla. Voit antaa jokaiselle kuluttajalle eri valet-avaimen. Heillä ei koskaan ole täyttä avainta tai mitään yksityisiä tietoja, joiden avulla he pääsevät käsiksi täyteen avaimeen.

Miten OAuth toimii

OAuth-transaktiossa on kolme pääasiallista toimijaa: käyttäjä, kuluttaja ja palveluntarjoaja. Tätä triumviraattia on kutsuttu hellästi OAuthin rakkauskolmioksi.

Esimerkissämme Joe on käyttäjä, Bitly on kuluttaja ja Twitter on palveluntarjoaja, joka hallitsee Joen suojattua resurssia (hänen Twitter-virtaansa). Joe haluaisi, että Bitly voisi lähettää lyhennettyjä linkkejä hänen streamiinsä. Näin se toimii:

Vaihe 1 – Käyttäjä osoittaa aikomuksensa

  • Joe (käyttäjä): ”Hei, Bitly, haluaisin, että voisit lähettää linkkejä suoraan Twitter-virtaani.”
  • Bitly (kuluttaja): ”Hienoa! Käyn kysymässä lupaa.”

Vaihe 2 – Kuluttaja saa luvan

  • Bitly: ”Minulla on käyttäjä, joka haluaisi minun postittavan hänen streamiinsä. Saanko pyynnön tunnuksen?”
  • Twitter (palveluntarjoaja): ”Token ja salaisuus.”

Salaisuutta käytetään estämään pyynnön väärentäminen. Kuluttaja käyttää salaisuutta jokaisen pyynnön allekirjoittamiseen, jotta palveluntarjoaja voi varmistaa, että se todella tulee kuluttajasovelluksesta.

Vaihe 3 – Käyttäjä ohjataan uudelleen palveluntarjoajalle

  • Bitly: ”OK, Joe. Lähetän sinut Twitteriin, jotta voit hyväksyä. Ota tämä merkki mukaasi.”
  • Joe: ”OK!”

<Bitly ohjaa Joen Twitteriin hyväksyntää varten>

Tämä on pelottava kohta. Jos Bitly olisi superhämärä Evil Co. se voisi avata ikkunan, joka näyttäisi Twitteriltä, mutta olisi todellisuudessa käyttäjänimesi ja salasanasi phishing. Varmista aina, että URL-osoite, johon sinut ohjataan, on todella palveluntarjoaja (tässä tapauksessa Twitter).

Vaihe 4 – Käyttäjä antaa luvan

  • Joe: ”Twitter, haluaisin valtuuttaa tämän Bitlyn antaman pyyntötunnisteen.”
  • Twitter: ”OK, varmuuden vuoksi haluat valtuuttaa Bitlyn tekemään X, Y ja Z Twitter-tililläsi?”
  • Joe: ”Kyllä!”
  • Twitter: ”OK, voit mennä takaisin Bitlyyn ja kertoa heille, että heillä on lupa käyttää pyyntö-tunnustaan.”

Twitter merkitsee pyyntö-tunnuksen ”hyväkuntoiseksi”, joten kun kuluttaja pyytää käyttöoikeutta, se hyväksytään (kunhan se on allekirjoitettu heidän jaetulla salaisuudellaan).

Vaihe 5 – Kuluttaja hankkii käyttöoikeustunnuksen

  • Bitly: ”Twitter, voinko vaihtaa tämän request tokenin access tokeniin?”
  • Twitter: ”

Vaihe 6 – Kuluttaja käyttää suojattua resurssia

  • Bitly: ”Haluaisin lähettää tämän linkin Joen streamiin. Tässä on pääsymerkkini!”
  • Twitter: ”

Skenaariossamme Joen ei koskaan tarvinnut jakaa Twitter-tunnuksiaan Bitlyn kanssa. Hän yksinkertaisesti delegoi pääsyn käyttämällä OAuthia turvallisella tavalla. Joe voi milloin tahansa kirjautua Twitteriin ja tarkastella myöntämiään käyttöoikeuksia ja peruuttaa tiettyjen sovellusten tokenit vaikuttamatta muihin sovelluksiin. OAuth mahdollistaa myös rakeiset käyttöoikeustasot. Voit antaa Bitlylle oikeuden lähettää viestejä Twitter-tilillesi, mutta rajoittaa LinkedInille vain lukuoikeuden.

OAuth 1.0 vs. OAuth 2.0

OAuth 2.0 on täydellinen uudelleensuunnittelu OAuth 1.0:sta, eivätkä ne ole yhteensopivia. Jos luot uuden sovelluksen tänään, käytä OAuth 2.0:aa. Tämä blogi koskee vain OAuth 2.0:aa, sillä OAuth 1.0 on vanhentunut.

OAuth 2.0 on nopeampi ja helpompi toteuttaa. OAuth 1.0 käytti monimutkaisia kryptografisia vaatimuksia, tuki vain kolmea virtaa eikä skaalautunut.

OAuth 2.0:ssa on sen sijaan kuusi virtaa erityyppisiä sovelluksia ja vaatimuksia varten, ja se mahdollistaa allekirjoitetut salaisuudet HTTPS:n kautta. OAuth-tunnuksia ei enää tarvitse salata päätepisteissä 2.0:ssa, koska ne salataan siirron aikana.

Muut resurssit

Toivottavasti tämä oli hyvä alkuopas, joka tutustuttaa sinut OAuthiin, joten kun seuraavan kerran näet ”Kirjaudu sisään Twitterillä” tai vastaavanlaisen delegoidun identiteettien todentamisen, sinulla on hyvä käsitys siitä, mistä on kyse.

Jos haluat sukeltaa syvemmälle OAuthin mekaniikkaan, tässä on muutamia hyödyllisiä linkkejä:

  • http://marktrapp.com/blog/2009/09/17/oauth-dummies
  • https://dev.twitter.com/docs/auth/oauth/faq
  • http://stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1
  • http://googlecodesamples.com/oauth_playground/

Vastaa

Sähköpostiosoitettasi ei julkaista.