OAuth autorizacija

Izvor: SIS Wiki

Skoči na: orijentacija, traži

Temu prijavio: Pavao Vlahović

Sadržaj

Uvod

Cilj ovog projekta je objašnjenje rada autentifikacijskih protokola OAuth 1.0 i OAuth 2.0. Osim toga, prikazat ću aplikaciju koja predstavlja implementaciju OAuth 2.0 razvojnog okvira. OAuth protokol relativno je novi protokol te se njegovo korištenje sve više povećava. U tradicionalnoj klijent-server arhitekturi, korisnik koristi svoje korisničko ime i lozinku za pristup resursima koji se nalaze na serveru. Razlog zbog kojeg je potrebna nova vrsta protokola je ta što razvojem web i Cloud servisa pojavila se potreba za pristupom treće strane prema korisničkim resursima. OAuth 1.0 i OAuth 2.0 omogućuju siguran pristup više aplikacija prema korisničkim resursima.

OAuth 1.0

Razvoj OAuth protokola započela je grupa web developera za Internet servise koji su željeli riješiti uobičajeni problem delegiranja i pristupanja zaštićenim resursima. Prva stabilna verzija OAuth protokola pojavila se 2007. godine, a 2009. godine bila je revizija te se koristi verzija OAuth 1.0a. OAuth je u tradicionalnu klijent-server arhitekturu dodao novu rolu: vlasnik resursa. Kako bi u potpunosti razumjeli protokol, moramo razumjeti njegove učesnike:

Klijent (client) - HTTP klijent koji ima mogućnost kreiranja OAuth autentificiranih zahtjeva.
Server (server) – HTTP server koji ima mogućnost prihvaćanja OAuth autentificiranih zahtjeva.
Zaštićeni resurs (protected resource) – resurs koji može biti dohvaćen sa server.
Vlasnik resursa (resource owner) – entitet koji ima mogućnost pristupanja i kontroliranja zaštićenih resursa.
Korisnički podaci (Credentials) – Uobičajeno korisničko ime i lozinka vlasnika resursa.
Token – jedinstveni identifikator koji izdaje server, a koristi klijent kako bi autentificirao vlasnika resursa prema serveru.

Ove pojmove lakše možemo objasniti uz poslovni slučaj. Na primjer, osoba se prijavila na servis za pohranu fotografija koristeći svoje korisničko ime i lozinku. Također, osoba želi koristiti servis za ispis fotografija za ispis tih fotografija, ali ne želi dijeliti svoje korisničko ime i lozinku sa servisom za ispi. OAuth omogućuje autentificiranu komunikaciju između servisa za ispis i servisa za pohranu fotografija. Slika prikazuje poslovni slučaj te povezuje fizičke pojmove s pojmovima u OAuth 1.0 komunikaciji.

U daljnjem tekstu objasniti ćemo komunikaciju između dva servisa koja su na slici prikazana kao OAuth 1.0. Dakle, postoji korisnik koji je prijavljen na servisu za pohranu fotografija i želi koristiti servis za ispis bez otkrivanja svojeg korisničkog imena i lozinke. Kako bi takva komunikacija bila moguća, servis za ispis mora biti poznat servisu za pohranu fotografija, odnosno servis za ispis mora se registriran kao klijent kod servisa za pohranu fotografija. Pretpostavimo da je servis za ispis već prije registriran kao klijenti i ima svoj identifikator (dpf43f3p2l4k3l03) i dijeljenom tajnom (kd94hf93k423kf44).

Osim toga, servis za pohranu fotografija mora imati mapirane sljedeće url-ove:

/initiate – služi za dobivanje privremenih podataka za autentifikaciju (credentials) za komunikaciju s servisom za pohranu fotografija

/authorize – služi za autorizaciju korisnika na servisu za pohranu fotografija.

/token – služi za dodjeljivanje tokena koji je potreban u daljnjoj komunikaciji.

Tijek komunikacije

1. Prije nego servis za ispis može pitati korisnika za pristup fotografijama, servis mora dohvatiti privremene podatke za autentifikaciju (credentials) od servisa za pohranu fotografija. To radi na način da šalje HTTPS POST zahtjev prema servisu za pohranu fotografija na url /initiate. U zaglavlju zahtjeva šalje svoj identifikator (dpf43f3p2l4k3l03) i dijeljenu tajnu (kd94hf93k423kf44).

2. Servis za pohranu fotografija prima zahtjev te provjerava ispravnost primljenih podataka. Ako su podaci ispravni, servis za pohranu fotografija dodjeljuje privremene podatke za autentifikaciju (credentials). Privremeni podaci za autentifikaciju (credentials) šalju se kao HTTP odgovor u zaglavlju {oauth_token: hh5s93j4hdidpola}.

3. Korisnik se preusmjerava na servis za pohranu fotografija na url: /authorize?oauth_token= hh5s93j4hdidpola. Korisnik se u ovome trenutku mora autorizirati svojim korisničkim imenom i lozinkom (ili nekim drugim autorizacijskim podacima).

4. Nakon uspješne autorizacije, korisnik, servisu za ispis, dopušta pristup fotografijama na servisu za pohranu fotografija. Kako bi se servis za ispis obavijestio o dodijeli prava, šalje se HTTP zahtjev prema servisu za ispis na url: /ready?oauth_token=hh5s93j4hdidpola&oauth_verifier=hfdp7dh39dks9884. „oauth_verifier“ predstavlja identifikator pod kojim je servisu za ispis dozvoljen pristup korisničkim fotografijama.

5. Korisnika se preusmjerava na servis za ispis te mu se prikazuje aplikacija za ispis fotografija.

6. U ovome trenutku servis za ispis ima potvrdu za pristup korisničkim fotografijama. Međutim, kako bi mogao pristupiti fotografijama, servis za ispis mora zatražiti token od servisa za pohranu fotografija. Taj token će se koristiti za svu dalju komunikaciju sa servisom za pohranu fotografija. Kako bi dohvatio token, servis za ispis, šalje HTTPS POST zahtjev prema servisu za pohranu fotografija na url: /token. Unutar zaglavlja šalje privremene podatke za autentifikaciju (credentials) i „oauth_verifier“ identifikator.

7. Servis za pohranu fotografija provjerava primljene podatke te ako su podaci ispravni odgovara s podacima o tokenu: oauth_token=nnch734d00sl2jdk&oauth_token_secret=pfkkdhi9sl3r4s00

8. Sada, servis za ispis fotografija može dohvatiti korisničke fotografije, uz uvjet da se prilikom slanja zahtjeva u zaglavlju nalazi dobiveni token. Ovakva vrsta komunikacija između ova dva servisa moguća je sve do trenutka kada token ne istekne ili korisnik odluči izbrisati pristup servisa za ispis do njegovih fotografija na servisu za pohranu fotografija.

Sljedeća slika prikazuje komunikaciju između klijenta i servera u OAuth 1.0 komunikaciji. Izvor slike: [1]

Prednosti i nedostaci

OAuth protokol je protokol koji omogućuje komunikaciju između dva servisa na način koji je opisan ranije u tekstu. Zbog toga samo njegovo postojana je prednost u komunikaciji. Problemi ovog protokola su ti što je protokol previše orijentiran na web te se njegovi nedostaci vide kod ostalih platformi. Na primjer kod mobilnih aplikacija, kako bi se korisnik autentificirao, aplikacija mora pokrenuti web preglednik te se korisnik unutar njega mora prijavljivati. Upravo iz takvih razloga, kreiran je OAuth 2.0 protokol/razvojni okvir. Ploča prikazuje stanje prednosti i nedostataka OAuth 1.0 protokola.

OAuth 2.0

AOuth 2.0 je, za razliku od AOuth 1.0, razvojni okvir. Razlog tome je nestandardiziranost određenih postupaka u AOuth 2.0 autentifikaciji. Međutim, novi razvojni okvir kreirao je novu arhitekturu i nove pristupe prilikom autentifikacije korisnika. U samoj dokumentaciji AOuth 2.0 razvojnog okvira stoji:

The OAuth 1.0 protocol ([RFC5849]), published as an informational document, was the result of a small ad hoc community effort. This Standards Track specification builds on the OAuth 1.0 deployment experience, as well as additional use cases and extensibility requirements gathered from the wider IETF community.

AOuth 2.0 nije kompatibilan s verzijom 1.0 jer su promjene u samoj arhitekturi rješenja prevelike za kreiranje kompatibilnosti. AOuth 2.0 posjeduje sljedeće role:

Vlasnik resursa (resource owner) – ne razlikuje se od vlasnika resursa kod verzije 1.0. Dakle, entitet koji ima mogućnost pristupanja i kontroliranja zaštićenih resursa.
Server resursa (resource server) – server s resursima zadužen je za čuvanje resursa korisnika. Klijent želi doći do resursa korisnika koji se nalaze na ovome serveru. Specifikacija OAuth 2.0 ne sprječava mogućnost da su server resursa i autorizacijski server isto računalo.
Klijent (client) – klijentska aplikacija koja želi pristupiti resursima svojih korisnika. Razlika između aplikacija klijenata OAuth 1.0 i OAuth 2.0 je ta što kod OAuth 2.0 aplikacija klijenta ne mora biti web preglednik nego može biti bilo kakva aplikacija.
Autorizacijski server (authorization server) – Server koji izdaje tokene klijentima nakon što uspješno autentificiraju vlasnika resursa.

Tijek komunikacije

Pošto je AOuth 2.0 razvojni okvir ne postoji jedinstveni tijek komunikacije već tijek ovisi o implementaciji. Apstraktni prikaz tijeka komunikacije vidljiv je na slici ispod.

Slika prikazuje 6. koraka koji se događaju u OAuth 2.0 komunikaciji:

1. Klijent zahtjeva autorizaciju korisnika kako bi mogao pristupiti zaštićenim resursima.

2. Korisnik se autorizira na nekoliko načina (ovisno o klijentskom zahtjevu). Time klijent dohvaća autorizacijske dozvole od korisnika.

3. Klijent zahtjeva pristupni token od autorizacijskog servera s autorizacijskim dozvolama klijenta.

4. Autorizacijski server provjerava podatke o klijentu s kojeg zahtjev dolazi i podatke o autorizacijskim dozvolama korisnika. Ako su podaci validni, autorizacijski server klijentu dodjeljuje token s kojim može pristupiti resursima tog korisnika

5. Klijent šalje zahtjev za korisničkim resursima te u zahtjevu navodi token koji mu je dodijelio autorizacijski token. Server s resursa provjerava ispravnost tokena te klijentu vraća tražene podatke.

Gore navedena komunikacija predstavlja apstraktni prikaz OAuth 2.0 komunikacije. Međutim, postoji nekolicina implementacije komunikacije, a svi ovise o načinu dodjele autorizacijske dozvole. Odnosno zbog koraka 1 i 2 u gornjem primjeru. Postoje sljedeće implementacije dodjele autorizacijskih dozvola:

Autorizacijski kod – koristi se kod klijentskih web orijentiranih aplikacija.
Implicitni – koristi se kod mobilnih ili web aplikacija.
Korištenjem korisničkih podataka za autentifikaciju (credentials) – korisnik upisuje svoje korisničko ime i lozinku.
Korištenjem klijentskih podataka za autentifikaciju (credentials) - koriste se kod aplikacija s API pristupom.

Prednosti i nedostaci

OAuth 2.0 novi je razvojni okvir OAuth protokola. Unatoč tome što developeri razvojnog okvira tvrde da je OAuth 2.0 nastao iz iskustva s OAuth 1.0, postoji krug korisnika koji nisu zadovoljni razvojnim okvirom. Članak [2] ukazuju na neke nedostatke koji se nalaze u OAuth 2.0 razvojnom okviru. Korisnicima koji su implementirali OAuth 1.0, savjetuje se da ostanu koristiti taj protokol. Razlog tome je taj što za migraciju s OAuth 1.0 na OAuth 2.0 najveće promjene događaju se kod klijentskih aplikacija koje uglavnom nisu pod našom kontrolom.

Aplikacija (Autorizacijski server i server resursa)

GitHub: https://github.com/pvlahovic1/sis_oauth2

U sklopu ovog projekta kreirana je aplikacija koja koristi OAuth 2.0 razvojni okvir za autentikaciju. Autorizacijski server i Server resursa predstavljaju jednu aplikaciju, ali njihove putanje su strogo odvojene. Za razvoj aplikacije korišten je Spring Boot razvojni okvir. Spring Boot unutar sebe posjeduje „spring security oauth2“ dodatak kojim se unutar Spring Boota omogućuje konfiguracija OAuth 2.0.

Resursi koje korisnik posjeduje na Serveru resursa su bilješke i literatura. Klijentskim aplikacijama potrebno je omogućiti pristup korisničkim resursima. Međutim, neki klijenti ne moraju imati pravo vidjeti sve korisničke resurse ili ne moraju imati pravo izvršavati sve CRUD operacije. Ovisno o klijentu, autorizacijski server dodjeljuje prava pristupa resursima pojedinih korisnika. ERA model aplikacije vidljiv je na sljedećoj slici.

Kao što se može vidjeti, korisnik može imati više resursa, a svaki resurs ima svoj tip resursa. Klijentima je omogućen pristup samo određenim tipovima resursa. Samim time, klijentske aplikacije mogu pristupiti samo zadanim tipovima resursa svojih korisnika. Svaki klijent ima svoj opseg koji opisuje koje operacije smije vršiti nad resursima. Dakle, neki klijenti smiju kreirati i brisati resurse, a neki ih smiju samo čitati.

Dalje u tekstu prikazat ću slike komunikacije aplikacije s aplikacijom.

Kako bismo mogli pristupiti resursima korisnika, moramo dohvatiti token kojim ćemo autentificirati korisnika kod autorizacijskog servera. Token dohvaćamo na način da šaljemo POST zahtjev prema aplikaciji s putanjom /oauth/token, a kao varijable šaljemo grant_type koji predstavlja način će se dodijeliti autorizacijske dozvole. Vrijednost varijable postavljena je na password. Odnosno, korisnik unosi svoje korisničko ime i lozinku. Također, osim korisnika, klijent mora poslati svoje podatke. Klijent šalje svoj id (fakultet_organizacije_i_informatike) i svoju tajnu. Slanjem zahtjeva, aplikacija provjerava unesene podatke te kreira token kojim možemo dohvatiti korisničke resurse. Vrijeme trajanja tokena iznosi 86400000 milisekundi, odnosno jedan dan. Opseg koji klijent ima je truest, što označava da klijent smije vršiti sve CRUD operacije nad korisničkim resursima.

Slanjem GET zahtjeva s putanjom /rest-api/dana, možemo dohvatiti sve podatke korisnika. Unutar urla, moramo navesti access_token. Token nam predstavlja podatke o korisniku i klijentu koji su se autentificirali. Pošto klijent s kojim želimo dohvatiti podatke ima opseg postavljen na truest, možemo dohvatiti podatke.

Dodavanje novog resursa mogu napraviti klijenti koji imaju opseg truest ili write. Za dodavanje resursa, moramo poslati PUT zahtjev s putanjom /rest-api/data. Također, ponovo moramo navesti access_token. Unutar tijela zahtjeva šaljemo JSON objekt s podacima od tipu resursa i sam resurs.

Brisanje resursa mogu napraviti klijenti koji imaju opseng truest ili delete. Kako bi obrisali postojeći resurs, šaljemo DELETE zahtjev s putanjom /rest-api/data. Kao i svaki put do sada, unutar urla moramo navesti access_token. Unutar tijela zahtjeva, šaljemo JSON objekt koji unutar sebe ima identifikacijsku oznaku resursa koji želimo obrisati. Ukoliko identifikacijska oznaka nije točna, aplikacija vraća grešku. Također, aplikacija vraća grešku ako klijent nema pravo pristupa tom tipu resursa ili korisnik nije vlasnik tog resursa.

Aplikacija (Implementacija prijave preko Facebooka)

GitHub: https://github.com/pvlahovic1/sis_oauth2_facebook

Aplikacija za prijavu preko Facebooka implementirana je u Spring Boot razvojnom okviru. Prije samog razvoja potrebno je registrirati novu aplikaciju na Facebooku. U OAuth jeziku to bi značilo da se klijent (moja aplikacija) mora registrirati kod servera (Facebook). Nakon registracije aplikacije, unutar dokumentacije možemo pronaći potrebne parametre za uspješnu komunikaciju.

Prednost ovakvog pristupa je u tome što naša baza ne mora sadržavati podatke o korisniku već sve podatke možemo preuzeti preko Facebooka. Zbog toga unutar ERA dijagrama ne moramo imati tablicu koja predstavlja role korisnika i tablice s posebnim podacima o korisniku.

Unutar tablice user nalaze se Facebook id i ime korisnika. Navedeni podaci dohvaćaju se prilikom prve prijave korisnika u aplikaciju. Data tablica predstavlja bilješke korisnika koje korisnik može kreirati i brisati.

Slika prikazuje ekran aplikacije na kojoj se potrebno prijaviti. Na slici je vidljivo da je jedini način prijave putem Facebooka. Nakon pritiska na gumb za prijavu, aplikacija nas preusmjerava na Facebook stranicu za prijavu.

Slika predstavlja Facebook stranicu za prijavu. Prilikom prijave Facebook od korisnika traži prihvaćanje svih dozvola koje aplikacija traži. Nakon uspješne prijave, Facebook korisnika preusmjerava natrag na početnu aplikaciju.

Slika prikazuje korisničko sučelje aplikacije. Unutar aplikacije svaki korisnik vidi samo svoje bilješke. Iste može brisati te po potrebi dodavati nove.

Zaključak

OAuth 1.0 i OAuth 2.0 su autentifikacijski protokoli kojima je cilj omogućiti novi način komunikacije. Protokoli omogućuju dohvaćanje resursa nekog korisnika bez potrebe da korisnik dijeli korisničke podatke sa serverom. OAuth 2.0 još nije standard, ali u praksi se sve više koristi. Postoje Internet skupine koje se protive standardizacije OAuth 2.0 razvojnog okvira. Daljnjim razvojem tehnologija, nastajat će novi sigurnosni zahtjevi koji će se morati detaljno analizirati i riješiti.