Nekoliko OAuth činjenica
- OAuth je otvoreni standard za autorizaciju / delegiranje ovlasti između aplikacija i servisa na internetu.
- OAuth standard održava Internet Engineering Task Force (IETF).
- Trenutna verzija je 2.0, a oficijelna specifikacija data je u RFC 6749.
Problem koji OAuth rješava ogleda se u tome da omogući internet korisnicima da odobre pristup aplikacijama i web stranicama pristup njihovim podacima na drugim sajtovima i servisima, ali na način da tim aplikacijama ne ustupe svoje kredencijale (password).
Zašto je potreban Oauth?
Kao što se može zaključiti iz gore navedenog, bez Oauth-a korisnici bi, u slučaju da trebaju omogućiti pristup nekoj “third-party” aplikaciji ili web stranici, pristup njihovim podacima/informacijama/accountu na nekom servisu (Facebook, Google ili bilo šta drugo) – morali toj aplikaciji ustupiti password kako bi ista operirala u njihovo ime i imala pune ovlasti nad servisom.
To je loše iz više razloga:
- Korisnik možda ne vjeruje u potpunosti vašoj aplikaciji i ne želi joj ustupiti password
- Čak i ako vjeruje, to generalno navikava korisnike na takvo ponašanje, što olakšava phishing napade
- Korisnik ne može ograničiti aplikaciju na samo određene akcije. Ako joj ustupi password, aplikacija ima maksimalne ovlasti
- Kada korisnik promijeni password, aplikacija ne može više funkcionirati.
- Shodno tome, ako korisnik želi onemogućiti pristup aplikaciji, jedini način je da promijeni password.
- Password postaje obavezan, što onemogućava neke vidove autentifikacije.
Šta Oauth omogućava umjesto toga?
Umjesto davanja passworda i punih ovlasti third party aplikaciji/web sajtu, Oauth omogućava da korisnik “ovlasti” aplikaciju da operira u njegovo ime, odobri joj tačno određena prava i sve to bez davanja passworda istoj. Kako to funkcionira? Tako što Oauth server preuzima autentikaciju korisnika na sebe, te zatim aplikaciji izdaje token u kom su sadržane potrebne informacije o korisniku i ovlastima. S tim tokenom aplikacija se autorizira servisu (resource serveru) na kome su korisničke informacije.
Osnovni pojmovi
Resource Server
Server koji hosta informacije koje su vlasništvo korisnika. To mogu biti fotografije, dokumenti, kalendar, kontakti, ali isto tako može biti i banking server ili bilo kakve druge strogo osjetljive informacije. Obično su te informacije izložene preko API-a.
Resource Owner
Korisnik aplikacije, vlasnik resursa/podataka koji se nalaze na Resource serveru.
Client
Aplikacija/Web site koja pravi API zahtjeve prema Resource serveru kako bi izvela akcije nad korisničkim podacima na resource serveru, u ime korisnika i sa autorizacijom
Authorization Server
Autorizacijski server vrši autentifikaciju korisnika (ili je delegira zasebnom servisu), te potom traži odobrenje, tj. saglasnost (Consent) od korisnika za datu aplikaciju (Client) da može operirati u njegovo ime. Authorization server i resource server mogu se nalaziti na istom URL-u/hostu, posebno za manje API.
Autorizacijski scenariji
Authorization Code Grant Flow
Ovaj flow je namijenjen za server side web aplikacije. Nakon što resource owner (korisnik) autorizira pristup svojim podacima, redirekta se nazad u web aplikaciju sa autorizacijskim kodom kao query parametrom u URL-u. Web aplikacija ponovo poziva Oauth i salje ovaj kod a u zamjenu dobije access token.
Implicit flow
Namijenjen za client side web aplikacije koje se pokreću u web browseru. Ovo je najjednostavniji flow od svih. Za razliku od Authorization Code flow-a, redirect odmah sadrži access token kao parametar u URL-u (umjesto autorizacijskog koda). Java script aplikacija zatim ekstraktuje token iz URL-a.
Resource Owner Flow
Ovaj flow podrazumijeva slanje korisnikovog (resource owner) imena i passworda unutar requesta. Koristi se samo za potpuno povjerljive klijentske aplikacije, npr. aplikacija razvijena od strane razvijatelja API-a. Iako se ovdje koristi username/password, ne pohranjuje se u aplikaciji/uređaju, već se pohranjuje token. To korisniku omogućava opoziv prava za aplikaciju, bez promjene passworda, te specificiranje samih ovlasti aplikaciji.
Client Credentials Flow
Ovaj flow namijenjen je za service-to-service komunikaciju, bez resource ownera, tj. Client pristupa API-u u svoje ime, ne u ime specifičnog korisnika. Ovdje se autenticira sama klijentska aplikacija/servis i njoj se izdaje token.
Foto: Kljevci, Sanski Most