OAuth 2.0-valtuutusprotokolla

OAuth 2.0-valtuutusprotokolla Lauri Savolainen Seminaariraportti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos Helsinki, 12. huhtikuuta 2013

HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta Fakultet Faculty Laitos Institution Department Matemaattis-luonnontieteellinen Tekijä Författare Author Lauri Savolainen Työn nimi Arbetets titel Title Tietojenkäsittelytieteen laitos OAuth 2.0-valtuutusprotokolla Oppiaine Läroämne Subject Tietojenkäsittelytiede Työn laji Arbetets art Level Aika Datum Month and year Sivumäärä Sidoantal Number of pages Seminaariraportti 12. huhtikuuta 2013 16 Tiivistelmä Referat Abstract Web-palvelut tarjoavat avoimia rajapintoja joita toiset tahot voivat hyödyntää tuottaakseen kokonaan uusia palveluita tai sovelluksia. Palveluiden käyttäjillä on usein palveluissa resursseja joita ei tulisi saattaa julkisesti näkyville tai muokattaviksi joihin kuitenkin julkisia rajapintoja hyödyntävien palveluiden tulisi päästä käsiksi. Koska rajapinnat ovat julkisia mutta resurssit ovat suojattuja tulee rajapinnan hyödyntäjällä olla resurssin omistajan myöntämä valtuutus. Valtuutus on mahdollista tehdä antamalla rajapintaa hyödyntävälle palvelulle samat todennuskeinot kuin käyttäjällä mutta tällöin rikotaan todentamisen perusideaa ja toisaalta todennuksen jakaminen ei ole aina käytännössä mahdollista. Valtuutuksen laajuutta ja kestoa on myös asianmukaista rajata tapauskohtaisesti mikä ei onnistu pelkällä todennuskeinon jakamisella. Todentamisen lisäksi tarvitaan siis täysin erillinen valtuuttamisprosessi. OAuth on nykyaikaisille web-palveluille suunnattu laajennettava avoin protokolla jota voidaan käyttää valtuuttamisen toteuttamiseen. Yksinkertaistettuna valtuutettava palvelu muotoilee valtuutuspyynnön joka määrittelee valtuutuksen laajuuden ja muodon. Käyttäjä nähtyään valtuutuspyynnön tiedot joko hyväksyy tai hylkää valtuutuksen. Valtuutuksen hyväksynnän jälkeen valtuutettu palvelu saa käyttöönsä valtuutusavaimen jolla pystytään suorittamaan valtuutuksen laajuuden mukaisia toimia käyttäjän resursseihin. OAuthin uusin 2.0-versio määrittelee uusia tapoja valtuutusprosessin toteuttamiseen jotka soveltuvat paremmin nykyaikaisille sulautetuille-, mobiili- sekä selainpohjaisille sovelluksille. ACM Computing Classification System (CCS): Authorization Avainsanat Nyckelord Keywords valtuuttaminen, web-sovellukset, oauth, soa, rajapinnat Säilytyspaikka Förvaringsställe Where deposited Muita tietoja Övriga uppgifter Additional information

Sisältö 1 Johdanto 3 2 Valtuuttaminen 3 2.1 Todentaminen ja valtuuttaminen................ 3 2.2 Valtuutus web-palveluissa.................... 4 2.3 Valtuutus vai todennus?..................... 4 2.4 Motivaatio todentamisesta erilliselle valtuuttamisprosessille. 4 2.4.1 Kiistämättömyys..................... 5 2.4.2 Valtuutuksen laajuus ja kesto.............. 5 2.4.3 Käytännön ongelmat salasanatodentamisen kanssa.. 5 2.4.4 Epäyhteensopivuus muiden todennustekniikoiden kanssa 5 3 OAuth 6 3.1 Historia, standardit........................ 7 3.1.1 OAuth 2.0......................... 7 3.1.2 Tulevaisuus........................ 8 3.2 OAuthin käyttö.......................... 8 3.2.1 Käsitteitä......................... 8 3.2.2 Palvelinpohjainen valtuutus ( authorization code grant ) 9 3.2.3 Asiakaspohjainen valtuutus ( implicit grant )..... 10 3.2.4 Salasanapohjainen valtuutus ( resource owner password credentials grant ).................... 11 3.2.5 Itsevaltuutus ( client credentials grant )........ 11 3.2.6 Muut valtuutustavat ja laajennettavuus........ 12 4 Esimerkkisovellus 12 4.1 Huomautuksia.......................... 12 4.2 Esimerkki............................. 12 Lähteet 16 2

1 Johdanto Nykyaikaiset web-palvelut hyödyntävät yhä suuremmissa määrin toisten webpalvelujen tarjoamia avoimia rajapintoja. Usein tämä toisten web-palvelujen rajapintojen hyödyntäminen tehdään loppukäyttäjän nimissä jolloin on tarpeellista todistaa rajapintaa tarjoavalle palvelulle, että käyttäjä on antanut luvan toimia hänen nimissään, eli ts. valtuuttanut rajapintaa hyödyntävän palvelun. Tämä seminaarityö tutustuu valtuutuksen käsitteeseen sekä OAuthvaltuutusprotokollaan käytännön esimerkin kera. Ensimmäisessä osassa määritellään valtuutuksen käsite ja sen rooli nykyaikaisissa web-palveluissa. Samalla myös esitetään muutamia syitä miksi valtuutus on tarpeellista toteuttaa erillisenä palveluna todentamisesta. Toisessa osassa esitellään laajasti käytössä olevaa OAuth-valtuutusprotokollaa, sen käyttötapoja ja nykytilaa. Kolmannessa osassa OAuth-valtuutusprotokollan toimintaa havainnollistetaan yksinkertaisella sovelluksella joka käyttäjän valtuutuksen avulla lisää merkintöjä käyttäjän Google-kalenteriin OAuth-protokollan avulla. 2 Valtuuttaminen 2.1 Todentaminen ja valtuuttaminen Todennuksella ( authentication ) tarkoitamme prosessia jonka avulla varmistetaan osapuolen (ihminen tai palvelu) identiteetti. Tyypillisesti todentaminen tapahtuu kysymällä toimijalta jotain jonka vain osapuoli ja mahdollisesti kysyjä tietää tai omistaa. Tälläisiä asioita ovat mm. salasanat, kryptografiset avaimet, toimijan sormenjälki tai avainkortti. Yleisimmin web-palveluissa käyttäjän todentaminen tapahtuu käyttäjän kertomalla vain hänen itsensä tiedossa oleva salasana. Valtuutuksessa ( authorization ) taas toimija (valtuuttaja) antaa kolmannelle osapuolelle (valtuutettu) luvan toimia hänen nimissään toisen osapuolen kanssa. Havainnollistaaksemme todennuksen ja valtuutuksen eroa otamme käytännön esimerkiksi saapuneen paketin noutamisen postista. Normaalisti paketin vastaanottaja paketin noudon yhteydessä todentaa henkilöllisyytensä esittämällä luotettavan henkilötodistuksen. Todentamalla itsensä noutaja todistaa olevansa paketin vastaanottaja. On kuitenkin mahdollista, että vastaanottaja haluaa, että joku toinen henkilö lunastaa paketin hänen puolestaan. Tällöin pelkkä noutajan todentaminen ei riitä koska paketin vastaanottaja ja lunastaja eivät ole sama henkilö. Paketin lunastaja täytyy siis valtuuttaa erillisellä valtakirjalla. Merkille pantavaa on myös se, että valtakirja ei anna valtuutetulle rajatonta oikeutta lunastaa valtuuttajalle osoitettuja paketteja vaan yleensä vain yksittäisen paketin rajattuna aikana. Valtuutuksen lisäksi on myös luultavasti tarpeellista erikseen todentaa valtakirjan haltijan 3

identiteetti paketin lunastuksen yhteydessä. 2.2 Valtuutus web-palveluissa Nykaikaiset web-palvelut tarjoavat usein julkisia rajapintoja toisille palveluille. Näiden rajapintojen avulla palvelut voivat hyödyntää toisia palveluita niiden tuottamisen sijaan. Hyödyntämällä olemassa olevia palveluita pystytään hyödyntämään jo toisaalla toteutettua toiminnallisuutta ja toisaalta parantamaan käytettävyyttä koska käyttäjän ei tarvitse opetella käyttämään useaa samaa toiminnallisuutta toteuttavaa järjestelmää. Palvelujen yhteistoiminnan helpottamiseksi olisi siis oltava erillinen ja helppo tapa antaa käyttäjälle mahdollisuus valtuuttaa palvelu käyttämään toista palvelua käyttäjän nimissä. Tämä tarve on suhteellisen uusi koska web-palvelujen kaikille avoimet rajapinnat ovat alkaneet yleistyä vasta viime aikoina. Tätä ennen oletuksena on ollut, että rajapintoja käytetään vain sisäisesti jolloin erillistä valtuutusta ei tarvita vaan pelkkä rajapinnan käyttäjän todentaminen on riittävä. 2.3 Valtuutus vai todennus? Valtuutusprotokolla-käsite ei ole kovin vakiintunut. Hyvänä esimerkkinä tästä voidaan pitää Googlen OAuth-valtuutusprotokollan esittelysivua jonka englanninkielinen versio käyttää sanaa authorization (valtuutus) kun taas suomenkielinen versio käyttää sanaa todennusprotokolla.[3] [?] Siitäkin huolimatta, että OAuth-standardin ylläpitäjät sekä viralliset standardit käyttävät authorization-sanaa jopa OAuthin oma dokumentaatio-wiki käyttää ristiriitaisesti authentication-sanaa OAuthin tarkoituksen kuvaamiseen. [1] Sekaannuksen syynä voi olla mahdollisuus käyttää valtuutusprotokollia epäsuorasti todentamisessa. Jos käyttäjä pystyy antamaan valtuutuksen voidaan yleensä myös olettaa, että käyttäjän identiteetti on samalla todennettu. Monet web-palvelut käytännössä hyödyntävät esim. OAuth-valtuutusta käyttäjien todentamisessa. Tämän lisäksi valtuutusprosessiin sisältyy myös valtuutetun toimijan erillinen todentaminen. Tässä työssä aikaisemmin esiteltyjen seikkojen vuoksi koen kuitenkin, että on tarpeellista puhua erikseen valtuutusprotokollista ja tehdä selvä ero niiden ja todentamisprotokollien välillä. 2.4 Motivaatio todentamisesta erilliselle valtuuttamisprosessille Käytännössä yksinkertaisin tapa valtuuttaa toimija olisi antaa valtuutetulle mahdollisuus käyttää jo olemassa olevaa todennusmekanismia. Valtuuttaja voisi esimerkiksi antaa valtuutetulle palvelulle salasanansa toiseen palveluun jossa valtuutettu voisi toimia aivan vapaasti valtuuttajan nimissä. 4

Ongelmana on kuitenkin se, että todennukseen perustuva valtuutus rikkoo todennuksen perusidean. Todentaminen yleensä perustuu siihen oletukseen, että vain todennettava pystyy todentamaan itsensä. Jakamalla todentamistavansa tämä oletus rikotaan täysin. Käyttäen aikaisemmin esiteltyä käytännön esimerkkiä pakettien noutamisesta tämä vastaisi sitä, että paketin vastaanottaja teettäisi ylimääräisen henkilöllisyystodistuksen ja antaisi sen valtuutetulle. Tämä lähestymistapa mahdollistaisi paketin noutamisen mutta samalla valtuutettu pystyisi tekemään mitä tahansa muuta valtuuttajan nimissä, kuten vaikkapa nostamaan lainan. 2.4.1 Kiistämättömyys Todennuksella monesti toteutetaan kiistämättömyyttä. Jos todentamisen perusoletus siitä, että vain toimija itse pystyy todentamaan itsensä, on voimassa voidaan osoittaa, että todennuksen avulla tehdyt teot ovat todennetun itsensä tekemiä. Jos todennus on jaettu usean toimijan kesken ei enää pystytä varmistumaan siitä, että kuka on tekojen tekijä. Valtuutuksen avulla voidaan pystyä erottamaan valtuuttajan ja valtuutetun teot toisistaan kiistämättömästi. 2.4.2 Valtuutuksen laajuus ja kesto Valtuutuksen yhteydessä on järkevää rajoittaa valtuutetun toimivalta koskemaan vain asianmukaisia toimia sekä samalla myös asettamaan tietty aikajakso jolloin valtuutus on voimassa. Jaettuun todennukseen perustuvassa valtuutuksessa valtuutuksen toimivaltaa ei ole mitenkään rajoitettu ja valtuutuksen kesto riippuu todennustavasta jotka ovat yleensä joko hyvin pitkä- (salasanat, biometriset) tai lyhytkestoisia (kertakäyttösalasanat, ajasta riippuvat). 2.4.3 Käytännön ongelmat salasanatodentamisen kanssa Käyttäjän vaihtaessa salasanansa valtuutuksen kohteena olevassa palvelussa valtuutus lakkaa olemasta. Palvelua ei pystytä hyödyntämään ennen kuin käyttäjä valtuuttaa hyödyntävän palvelun uudestaan kertomalla uuden salasanansa. Monet palvelut kehoittavat käyttäjiä pitämään salasanansa omana tietonaan kaikissa tapauksissa. Jotkut palvelut jopa yksiselitteisesti kieltävät salasanan jakamisen säännöissään. 2.4.4 Epäyhteensopivuus muiden todennustekniikoiden kanssa Salasanojen lisäksi käytetään myös muita todennustekniikoita (usein salasanojen kanssa samanaikaisesti, eli ns. two-factor authentication ). Muita 5

todennustekniikoita ovat mm. kertakäyttösalasanat, biometriset todennustekniikat sekä erilaiset fyysiset tunnisteet. Näiden todennustekniikoiden jakaminen valtuuttamista varten on hyvin hankalaa ja käytännössä mahdotonta silloin, jos valtuutetun tulee toimia valtuuttajan nimissä silloin kun valtuutettu ei ole välittömässä yhteydessä valtuuttajaan.[2, s. 4] 3 OAuth Tällä hetkellä loppukäyttäjille suunnatuissa web-palveluissa ylivoimaisesti suosituin tapa toteuttaa valtuuttaminen on soveltaa avointa OAuthprotokollaa. Protokollan standardi suppeimmillaan määrittelee valtuutusprosessin osapuolet, valtuutustavat sekä -rajapinnat ja tavat joilla valtuutus voidaan tehdä turvallisesti julkisen verkon yli. Protokollasta on julkaistu useita kuvauksia, standardeja sekä laajennuksia mutta oletuksena tässä työssä käsitellään RFC 6749 The OAuth 2.0 Authorization Frameworkstandardiehdotusta joka määrittelee valtuutusprotokollan perustoiminnallisuuden. Kuva 1: Valtuutusprosessi yleistettynä Standardi määrittelee erillisen todennuksesta täysin erillisen valtuutusprosessin. Tyypillisesti OAuthissa valtuutus tapahtuu siten, että valtuutusta haluava palvelu ohjaa loppukäyttäjän valtuutuksen kohteena olevan palvelun valtuutuspalvelimelle jossa käyttäjä hyväksyy valtuutuksen ja saa valtuutusavaimen joka taas välitetään valtuutettavalle. Valtuutettu palvelu pystyy käyttämään avainta suorittaakseen toimia valtuuttajan nimissä 6

valtuutuksen kohteena olevassa palvelussa. Käytännössä valtuutusprosessi on hieman monimutkaisempi ja OAuth määrittelee eri skenaarioihin sopivia valtuutusprosesseja mutta perusidea on useimmiten sama. 3.1 Historia, standardit Ennen OAuthia monet suuret julkisten web-palvelujen tarjoajat olivat toteuttaneet omia valtuutusprotokollia rajapintojensa käyttöä varten.[2, s. 1] Protokollat kuten Googlen AuthSub ja Yahoon BBAuth toimivat samoin kuin OAuthin palvelinpohjainen valtuutus, käyttäjä ottaa yhteyttä palveluun, todentaa itsensä ja välittää rajapintaa hyödyntävälle asiakassovellukselle palvelusta saadun käyttöavaimen.[2, s. 1] OAuthin kehitystyö alkoi vuosien 2006-2007 vaihteessa alkuperäisten kehittäjien yrittäessä selvittää mahdollisuuksia hyödyntää jo silloin käytössä ollutta OpenID-todennusprotokollaa rajapintavaltuutuksissa. Selvityksen yhteydessä tarkasteltiin myös jo silloin olemassa olleita yksittäisten palveluntarjoajien toteuttamia suljettuja valtuutusprotokollia. Selvityksen lopputuloksena oli, että rajapintojen valtuuttamiselle ei ollut mitään yhteistä ja avointa standardia. [6] Vuoden 2007 aloitettiin standardin ensimmäisen version laatiminen ja lokakuussa 2007 julkaistiin ensimmäinen valmis versio standardista (OAuth Core 1.0 final draft). Myöhemmin standardista julkaistiin OAuth core 1.0 Revision A-versio, joka korjasi ensimmäisessä versiossa ilmennyttä tietoturvaaukkoa. Viimeinen versio OAuth 1.0-standardista on IETF:n julkaisema RFC5849-dokumentti. 3.1.1 OAuth 2.0 OAuthin ensimmäinen versio oli suhteellisen menestynyt mutta standardia soveltavien rajapintojen toteutamisen yhteydessä ilmaantui tarpeita joiden vuoksi nähtiin tarpeelliseksi luoda uusi taaksepäin epäyhteensopiva OAuth 2.0-standardi.[4] OAuthin ensimmäisen version soveltamisen hankalimpana asiana on pidetty protokollan vaatimaa tapaa allekirjoittaa pyynnöt kryptografisesti. [4] 2.0-versio protokollasta mahdollistaa yksinkertaistetumman pyyntöjen todennuksen vaatimalla suojattua yhteyttä osapuolien välillä. Tämä yksinkertaistaa protokollan toteuttamista mutta toisaalta toteuttajan tulee huolehtia siitä, että yhteys on suojattu asianmukaisesti.[7, s. 57] Ensimmäinen versio OAuthista oli tarkoitettu ensisijaisesti ns. perinteisille asiakas-palvelin-web-sovelluksille joissa valtuutettu web-sovellus toimii pääasiassa omalla palvelimellaan erillään loppukäyttäjän päätelaitteesta.[4] OAuth 2.0 tarjoaa vaihtoehtoisia valtuutustapoja jotka soveltuvat paremmin mobiili-, sulautetuille- ja pelkästään käyttäjän selaimessa ajettaville sovelluksille. 7

Uusi versio OAuthista parantaa protokollan skaalautuvuutta käyttämällä erillisiä lyhytkestoisia avaimia joiden validius voidaan tarkistaa ilman tilanhallintaa joka usein tarkoittaa suhteellisen hitaita tietokantapyyntöjä. [5] Ensimmäinen luonnos OAuth 2.0sta julkaistiin 2010 ja lopullinen versio standardista julkaistiin RFC 6749-dokumenttina. Standardin uutuudesta huolimatta monet rajapintojen tarjoajat ovat jo toteuttaneet standardin tai sen luonnosten mukaisia valtuutusrajapintoja. 3.1.2 Tulevaisuus OAuth 2.0:n ydinstandardi jättää määrittelemättä paljon aiottua toiminnallisuutta tarkoituksellisesti. Tulevaisuudessa määriteltävästä toiminnallisuudesta mainitaan esimerkkeinä asiakassovellusten dynaaminen rekisteröinti joka tällä hetkellä tapahtuu useimmiten etukäteen protokollan ulkopuolella sekä rajapintojen sijaintien ja tuettujen toiminnallisuuksien löytäminen niiden manuaalisen määrittelemisen sijaan. [7, s. 11] Kirjoitushetkellä OAuth-protokollan standardien kehittämisestä vastaavan työryhmällä on aktiivisessa kehityksessä 8 standardia jotka laajentavat OAuthin toiminnallisuutta. Uusia ominaisuuksia ovat mm. OAuthin ensimmäisen version käyttämä pyyntöjen allekirjoitus, tuki valtuutusten lakkauttamiselle, SAML 2.0-tuki ja aikaisemmin mainittu asiakassovellusten dynaaminen rekisteröinti. Standardista on haluttu tehdä helposti laajennettava [7, s. 11] sekä uusien standardien että yksittäisten standardia soveltavien rajapintojen kohdalla. Myöhemässä osassa esitellään lyhyesti miten yksittäiset rajapinnat voivat laajentaa OAuth-valtuutusprotokollaa. 3.2 OAuthin käyttö Itse protokollan toteutus tapahtuu suojatuilla HTTP-pyynnöillä [7, s. 4] joissa tietoa välitetään pyynnön parametreissa, otsikkotiedoissa sekä JSONsisältönä. 3.2.1 Käsitteitä Ehkä oleellisin asia OAuthin käsitteiden suhteen on huomata, että käyttäjällä tarkoitetaan valtuutettua palvelua eikä valtuutettua palvelua käyttävää loppukäyttäjää. Resurssi ( resource ) on valtuutuksen kohde (esim. loppukäyttäjän kalenteri) Asiakas ( client ) on sovellus (esim. web-sovellus, selaimessa toimiva sovellus, mobiilisovellus) joka resurssin omistajan valtuutuksella tekee resurssiin kohdistuvia pyyntöjä. 8

Resurssin omistaja ( resource owner ) on resurssin ensisijainen omistaja joka pystyy antamaan muille tahoille valtuutuksia resurssin käyttämiseksi. Resurssipalvelin ( resource server ) on palvelin jolla resurssi sijaitsee. Valtuutuspalvelin ( authorization server ) luo valtuutusta vastaavia avaimia resurssin omistajan onnistuneen todennuksen ja valtuutuksen hyväksymisen jälkeen. Valtuutuspalvelin voi olla sama toimija kuin resurssipalvelin mutta yksi valtuutuspalvelin voi hoitaa useamman resurssipalvelimen valtuutukset. 3.2.2 Palvelinpohjainen valtuutus ( authorization code grant ) Yleisin tapa käyttää OAuthia on palvelinpohjainen valtuutus joka soveltuu parhaitten perinteisille web-sovelluksille joita suoritetaan erillään loppukäyttäjästä omalla palvelimellaan. Tämä käyttötapa vastaa myös eniten OAuth 1.0-protokollaa mutta laajentaa sitä joltain osin. 1. Resurssin omistaja yrittää käyttää asiakassovellusta joka tarvitsee valtuutuksen resurssiin 2. Asiakassovellus ohjaa resurssin omistajan valtuutuspalvelimelle jossa saatuaan kuvauksen valtuutuksen laajuudesta ja kohteesta resurssin omistaja voi hyväksyä tai hylätä valtuutuksen. 3. Hyväksyttyään valtuutuksen valtuutuspalvelin ohjaa resurssinomistajan takaisin asiakassovellukseen käyttämällä linkkiä jonka parametrina välitetään valtuutuskoodin ( authorization grant ) asiakassovellukselle. 4. Saatuaan valtuutuskoodin asiakassovellus ottaa yhteyttä valtuutuspalvelimeen. Todennettuaan itsensä ja välitettyään valtuutuskoodin asiakassovellus saa rajatun aikaa voimassa olevan käyttöavaimen ( access token ) sekä mahdollisesti uudistamisavaimen ( refresh token ) jota voidaan käyttää uusien käyttöavainten hakemiseen. 5. Asiakassovellus ottaa yhteyttä resurssipalvelimeen ja lähettää resurssiin kohdistuvan pyynnön resurssipalvelimelle joka joko hyväksyy tai hylkää pyynnön. 6. Jos käyttöavaimen voimassaoloaika umpeutuu tai avain hylätään ja asiakassovellus on saanut uudistamisavaimen aikaisemmassa vaiheessa asiakassovellus hakee uuden käyttöavaimen valtuutuspalvelimelta. Merkittävin ero aikaisemmassa osassa esitettyyn yksinkertaistettuun valtuutusprotokollaan on käyttäjän välittämän valtuutuksen vaihtaminen varsinaiseen käyttöavaimeen jota käytetään resurssiin kohdistuvien pyyntöjen tekemiseen sekä lyhytaikaisen käyttöavaimen uudistamisprosessi. Koska varsinainen käyttöavain hankitaan täysin loppukäyttäjästä erillisellä yhteydellä jonka yhteydessä asiakassovellus todennetaan voidaan kiistämättömästi erottaa käyttäjän pyynnöt sekä valtuutuksella tapahtuvat pyynnöt, eli ts. 9

Kuva 2: Palvelinpohjaisen valtuutuksen vaiheet asiakassovellus ei voi esiintyä loppukäyttäjänä eikä loppukäyttäjä asiakassovelluksena. 3.2.3 Asiakaspohjainen valtuutus ( implicit grant ) Edellä kuvailtu palvelinpohjainen valtuutus soveltuu hyvin tyypillisille websovelluksille mutta esimerkiksi pelkästään käyttäjän selaimessa tai älypuhelimessa ajettavalle sovellukselle valtuutusprosessi on tarpeettoman monimutkainen.[4] Toisaalta asiakassovellus ei pysty todentamaan itseään luotettavasti koska todentamiseen vaadittu tieto sijaitsee loppukäyttäjän päätelaitteella eikä erillisellä palvelimella.[7, s. 51] OAuth 2.0:n uusi asiakaspohjainen valtuutustapa soveltuu paremmin tälläisiin sovelluksiin. 1. Asiakassovellus (tyypillisesti web-selaimessa suorittuva Javascript-sovellus) tarvitsee valtuutuksen resurssiin. 2. Asiakassovellus ohjaa resurssin omistajan valtuutuspalvelimelle käyttäen osoitetta jossa määritellään valtuutuksen laajuus, uudelleenohjausosoite sekä asiakassovelluksen tunniste. 3. Jos resurssin omistaja hyväksyy valtuutuksen hänet ohjataan edellisen pyynnön mukaiseen uudelleenohjausosoitteeseen jonka perään lisätään #-erottimen jälkeen käyttöavain ja sen käyttöajan pituus. Koska nämä tiedot lisätään #-merkin jälkeen ne eivät välity pyynnössä palvelimelle vaan ainoastaan pyynnön tuloksena saatavalle dokumentille. 4. Uudelleenohjausosoitteen dokumenttiin upotettu asiakassovellus jäsentää #-merkin jälkeiset tiedot ja voi alkaa käyttämään resurssia käyttöavaimen avulla. 10

Pääerona palvelinpohjaiseen valtuutukseen on, että asiakassovellus ei todenna itseään valtuutuspalvelimelle ja valtuutuksessa ei käytetä erillisiä uudistamisavaimia tai valtuutuskoodia. Asiakassovellus saa suoraan käyttöavaimen valtuutuspalvelimelta käyttäjän hyväksyttyä valtuutuksen ja jos avaimen käyttöaika umpeutuu joudutaan hankkimaan käyttäjältä kokonaan uusi valtuutus. Useimmiten valtuutuspalvelimet myöntävät uuden käyttöavaimen ilman resurssin omistajan erillistä hyväksyntää ensimmäisen valtuutuskerran jälkeen joten uuden valtuutuksen hankkiminen voidaan tehdä käyttäjältä piilossa. 3.2.4 Salasanapohjainen valtuutus ( resource owner password credentials grant ) Valtuuttaminen voidaan myös tehdä resurssin omistajan käyttämän salasanan avulla. Toisin kuin edellä esiteltyyn ongelmalliseen tapaan toteuttaa valtuutus, salasanaa ei tarvitse tallettaa valtuutuksen hankkimisen jälkeen. Tätä valtuutustapaa suositellaan käytettäväksi vain silloin jos asiakassovellus on jonkin luotettavan tahon hallinnassa. 1. Asiakassovellus tarvitsee valtuutuksen resurssiin 2. Asiakassovellus kysyy resurssin omistajan käyttämää salasanaa 3. Saatuaan salasanan asiakassovellus lähettää salasanan valtuutuspalvelimelle ja saa vastauksena käyttöavaimen ja mahdollisen uudistusavaimen jota voidaan käyttää uusien käyttöavainten hankkimiseen. Salasanapohjainen valtuutus on valtuutustavoista yksinkertaisin toteuttaa ja ei vaadi käyttäjän uudelleenohjaamista valtuutuspalvelimelle tai ylipäätänsä web-selainta. Kuitenkin salasanan jakamiseen liittyvät tietoturvaongelmat ja luotettava valtuutuksen laajuuden rajaamisen mahdottomuus tarkoittavat sitä, että tätä valtuutustekniikkaa tulisi käyttää vain hyvin rajatuissa tapauksissa joissa asiakassovellukseen voidaan luottaa.[7, s. 56] 3.2.5 Itsevaltuutus ( client credentials grant ) Käyttämällä palvelinpohjaisen valtuutusprosessin yhteydessä tapahtuvaa todennustapaa asiakassovellus voi myös valtuuttaa itsensä. Itsevaltuutusta voidaan käyttää esimerkiksi asiakassovelluksen omien resurssien hallintaan tai muiden resurssien jos valtuutus niihin on saatu jotain muuta kautta ennalta. Itsevaltuutuksessa asiakassovellus ottaa yhteyttä valtuutuspalvelimeen kuten palvelinpohjaisessa valtuutuksessa mutta ilmoittaa tekevänsä itsevaltuutuksen. Pyynnön yhteydessä asiakassovellus myös todentaa itsensä. Vastauksena asiakassovellus saa käyttöavaimen. 11

3.2.6 Muut valtuutustavat ja laajennettavuus Perusstandardissa esiteltyjen neljän valtuutustavan lisäksi rajapinnan tarjoaja voi toteuttaa omia standardin ulkopuolisia valtuutustapoja. Käytetty valtuutustapa kerrotaan valtuutuspyynnön yhteydessä parametrina jossa voidaan myös sallia rajapintakohtaisia arvoja tietyn muotoisina. [7, s. 41] Valtuutustapojen lisäksi rajapinnan tarjoaja voi määritellä uusia käyttöavaintyyppejä, pyyntö- ja vastausparametreja sekä uusia virheilmoituksia vastaamaan rajapinnan omia tarpeita.[7, s. 49] 4 Esimerkkisovellus Valtuutusprotokollan soveltamista käytännössä voidaan havainnollistaa yksinkertaisella esimerkillä jossa luodaan web-palvelu joka hyödyntää toisen palvelun rajapintaa käyttääkseen käyttäjän henkilökohtaista resurssia johon tarvitaan valtuutus. Esimerkkipalvelumme sisältää tiedot seminaaripäivämääristä- ja aiheista ja lisää ne käyttäjän luvalla käyttäjän Google-kalenteriin. OAuthin käsitteistön mukaisesti resurssin omistaja on palvelun käyttäjä, asiakassovellus on seminaarikalenteripalvelu itse, valtuututuspalvelin on Googlen oma OAuthpalvelin, resurssipalvelin on Google Calendar-palvelu ja resurssi on käyttäjän oma kalenteri. 4.1 Huomautuksia Esimerkkipalvelu on toteutettu Pythonin Flask-web-ohjelmointikehyksellä ja sitä ajetaan omalla erillisellä palvelimellaan. Valtuutuksessa käytetään palvelinpohjaista valtuutusta jossa käyttäjä välittää sovellukselle valtuutuskoodin jonka avulla pystytään hankkimaan varsinainen käyttöavain. Yksinkertaisuuden vuoksi palvelun toteuttava sovellus ei sisällä virheenkäsittelyä eikä noudata kaikkia hyviä käytäntöjä, kuten esimerkiksi stateparametrin asettamista satunnaiseksi ja sen tarkistamista. Käytännössä OAuth-protokollaa käyttävä sovellus tulisi toteuttaa jonkin OAuth-kirjaston avulla. Käytännössä jokaiselle suositulle ohjelmointiympäristölle on jo toteutettu OAuth-kirjasto. 4.2 Esimerkki Ennen käyttöönottoa asiakassovellus on rekisteröity Googlen rajapintasivustoilla ("Google APIs console") omaksi sovellukseksi jolle on annettu lupa käyttää Googlen kalenteri-rajapintaa. Rekisteröitymisen yhteydessä sovelluksesta on annettu nimi ja lyhyt kuvaus ja se on assosioitu sovelluksen ylläpitäjän Google-tunnukseen. Samalla on myös määritelty osoitteet joinne valtuutuspyyntöjen vastauksia voidaan välittää, tietoturvasyistä kaikki 12

osoitteet joita ei ole erikseen sallittu ovat estetty. Rekisteröitymisen jälkeen rajapintasivusto on luonut asiakassovellukselle tunnisteen ("Client ID") ja salasanan ("Client secret") joita käytetään valtuutusprosessin aikana asiakassovelluksen tunnistamiseen sekä todentamiseen. Kuva 3: Asiakassovelluksen rekisteröinti Käyttäjän tehdessä pyynnön.../authorize-osoitteeseen pyyntö ohjataan sovelluksen authorize-pyyntöjenkäsittelijään joka luo osoitteen uudelleenohjausta varten ja ohjaa käyttäjän Googlen valtuutuspalvelimelle. @app. r o u t e ( / a u t h o r i z e ) def a u t h o r i z e ( ) : params = { response_type : code, c l i e n t _ i d : CLIENT_ID, r e d i r e c t _ u r i : u r l _ f o r ( c a l l b a c k, _external=true ), scope : h t t p s : / /www. g o o g l e a p i s. com/ auth / c a l e n d a r + h t t p s : / /www. g o o g l e a p i s. com/ auth / u s e r i n f o. p r o f i l e, access_type : o n l i n e, approval_prompt : f o r c e s t a t e : STATE, } return r e d i r e c t (GOOGLE_OAUTH + auth? + u r l l i b. u r l e n c o d e ( params ) ) Params-muuttuja määrittelee uudelleenohjauksessa käytettävät parametrit ja parametrit liitetään GOOGLE_OAUTH_URL-vakion määrittelemän valtuutuspalvelimen osoitteen perään. response_type Kertoo että valtuutuksessa käytetään palvelinpohjaista valtuutusta, asiakassovelluksessa arvo olisi token client_id Asiakassovelluksen yksilöivä tunniste, valtuutuksen yhteydessä käyttäjälle näytetään asiakassovelluksen tiedot (nimi, logo) 13

redirect_uri Osoite johon käyttäjä ohjataan valtuutuksen hyväksynnän jälkeen valtuutuskoodin kera scope Määrittelee valtuutuksen laajuuden, valtuutus kattaa käyttäjän kalenteripalvelut sekä profiilipalvelun (nimi, sähköpostiosoite jne.) access_type Määrittelee valtuutuksen keston, koska valtuutusta tarvitaan vain lyhyen aikaa annetaan parametrin arvoksi online jolloin saadaan pelkästään rajatun aikaa voimassa oleva käyttöavain eikä uudistamisavainta. Parametrillä offline saataisiin myös uudistamisavain approval_prompt Käyttäjän tulee hyväksyä valtuutus joka kerta vaikka valtuutus olisi jo aikaisemmin myönnetty state Ns. cross-site request forgery-hyökkäyksien torjuntaan tarkoitettu tunniste, tämä lisätään valtuutuskoodin oheen uudelleenohjauksessa ja oikeassa sovelluksessa tämä tulisi tarkistaa Saatuaan uudelleenohjauksen vastauksena käyttäjän web-sovellus lähettää pyynnön Googlen valtuututuspalvelimelle ja saa vastauksena web-sivun jossa käyttäjä näkee valtuutuksen tiedot ja voi joko hyväksyä tai hylätä valtuutuksen. Jos käyttäjä ei ole kirjautuneena sisään Google-palveluihin hänen tulee kirjautua sisään jotta valtuutus voidaan tehdä. Kuva 4: Käyttäjän näkemä valtuutuksen yhteenveto Valtuutuksen hyväksynnän jälkeen käyttäjä uudelleenohjataan esimerkkipalveluun aikaisemmin määritellyn redirect_uri-parametrin mukaiseen osoitteeseen johon on liitetty parametrit code ja state joiden arvoina ovat valtuutuskoodi ja ensimmäisessä uudellenohjauksessa käytetty state-parametrin arvo. Pyynnön käsittelee sovelluksessa callback-pyyntöjenkäsittelijä. @app. r o u t e ( / o a u t h c a l l b a c k ) def c a l l b a c k ( ) : code = r e q u e s t. a r g s. get ( code ) params = { 14

code : code, c l i e n t _ i d : CLIENT_ID, c l i e n t _ s e c r e t : CLIENT_SECRET, r e d i r e c t _ u r i : u r l _ f o r ( c a l l b a c k, _external=true ), grant_type : a u t h o r i z a t i o n _ c o d e, } access_token = r e q u e s t s. post (GOOGLE_OAUTH + token, data=params ). j s o n ( ) [ access_token ] add_calendar ( access_ token ) return " L i s ä ys o n n i s t u i " Käsittelijä purkaa valtuutuskoodin käyttäjän pyynnöstä, hakee sen avulla valtuutuspalvelimelta käyttöavaimen ja lopulta tekee käyttäjän kalenteriin rajapintakutsuja erillisessä metodissa käyttäen saatua käyttöavainta. Käyttöavaimen hakemiseksi valmistellaan pyynnön parametrit: code Käyttäjän välittämä valtuutuskoodi client_id Asiakassovelluksen tunniste, sama kuin edellä client_secret Asiakassovelluksen salasana grant_type Arvo authorization_code kertoo, että kyseessä on palvelinpohjainen valtuutus. redirect_uri Valtuutuksen saamiseksi alunperin käytetty uudelleenohjausosoite, osoitteen tulee olla sama kuin edellä jotta voidaan varmistua siitä, ettei valtuutuskoodia ole kaapattu käyttämällä väärennettyä uudelleenohjaus-osoitetta. Parametreilla client_id ja client_secret asiakassovellus samalla todentaa itsensä valtuutuspalvelimelle. Käyttöavainpyyntö lähetetään Googlen valtuutuspalvelimelle jonka JSON-vastauksesta voidaan lukea käyttöavain muuttujaan access_token. Koska käyttöavainpyynnön yhteydessä asiakassovellus on tunnistaunut salasanallaan ja käyttöavain ei ole käyttäjän nähtävissä toteutuu molemminpuolinen kiistämättömyys - asiakassovellus ei voi toimia käyttäjän nimissä eikä käyttäjä asiakassovelluksen. Kuva 5: Käyttäjän kalenteri valtuutuksen ja rajapintakutsujen jälkeen Valtuutuksen jälkeen käyttäjä voi todeta, että esimerkkipalvelun seminaariajat ovat lisätty käyttäjän kalenteriin. Valtuutusprotokollaa soveltamalla 15

on voitu siis yhdistää kaksi web-palvelua ilman, että käyttäjän tietoturva on heikentynyt kohtuuttomasti - valtuutettu sovellus ei voi kaapata käyttäjän Google-tunnuksia, lukea käyttäjän sähköposteja eikä myöskään tehdä muutoksia kalenteriin valtuutuksen umpeuduttua. Lähteet [1] al, Messina et: FrontPage, maaliskuu 2013. http://wiki.oauth.net/w/ page/12238516/frontpage. [2] Boyd, Ryan: Getting Started with OAuth 2.0. O Reilly Media, 2012, ISBN 978-1449311605. [3] Google: OAuth-esittely, maaliskuu 2013. https://support.google.com/ a/bin/answer.py?hl=fi&answer=61017. [4] Hammer, Eran: Planning for OAuth 2.0, marraskuu 2009. http:// hueniverse.com/2009/11/planning-for-oauth-2-0/. [5] Hammer, Eran: Introducing OAuth 2.0, toukokuu 2010. http:// hueniverse.com/2010/05/introducing-oauth-2-0/. [6] Hammer-Lahav, Eran: Introduction, marraskuu 2012. http://oauth. net/about/. [7] Hardt, Dick ja WG, OAuth: The OAuth 2.0 Authorization Framework. IETF RFC 6749, lokakuu 2012. 16