Prije nego što napišem članak kojim ću pojasniti zašto više ne treba koristiti Implicit Grant u novim aplikacijama, potrebno je ipak da ukratko opišem sam ovaj flow. Što se tiče odluke koristiti ili ne, za sada neću ulaziti u detalje – ono što je ključno napomenuti je da je sam grant nastao kao kompromisno rješenje, kako bi i Client Side Java Script aplikacije mogle koristiti Oauth.
Razlozi za korištenje ovog kompromisa su sada prestali i za nove aplikacije se preporučuje Authorization Code Flow sa PKCE proširenjem, a Implicit ostaje kao “obsolete” – i dalje funkcionira isto i ne mijenja se ništa po pitanju sigurnosti, ali nove aplikacije ne treba graditi na ovom grantu.
Implicit je pojednostavljena verzija Code Authorization Granta, namijenjena browser baziranim (Java script i sl.) klijentskim aplikacijama (podsjetimo se, Authorization Code Grant je namijenjen za server bazirane aplikacije).
Ta pojednostavljenost se ogleda u tome da se sastoji samo iz jednog koraka tj. poziva, pri kom se odmah dobije token. Ne izdaje se “authorization code” koji se u drugom koraku razmjenjuje za token, kao što je to slučaj kod Code Authorization Flow, već se odmah na prvom pozivu izdaje access token.
Pri tome se, također, ne autenticira klijent tj. aplikacija.
Razlog za to leži u tome što je u pitanju browser based aplikacija, koja po svojoj prirodi, nije u mogućnosti na siguran način da čuva podatke za klijentsku autentikaciju – tako da se client_secret ne šalje u requestu. Oauth ovakvog klijenta tretira kao “untrusted“, “public” što ovisno o konkretnoj implementaciji može imati konsekvence na opseg ovlasti (scopes) koje će odobriti.
Specifičnost ovog flow-a je takođe što ne uključuje poseban protokol za dobavljanje refresh tokena.
Ovaj flow podrazumijeva da je korisnički agent (browser) potpuno siguran, nemodificiran i povjerljiv – u suprotnom je kompromitiran kompletan ovaj flow.
Tipičan poziv za ovaj flow je sljedeći:
GET
https://oauth-server.com/authorize
?response_type=token
&client_id=983509489
&redirect_uri=https%3A%2F%2Four-app.com%2Fcallback
&scope=read+write
&state=xljfef209wu0939
Pojašnjenje parametara:
- response_type = token – daje signal serveru da će se koristiti implicit flow i da očekuje token odmah u odgovoru.
- client_id – uobičajeni id klijenta koji se koristi, dobije se prilikom registracije. Ne šalje se client_secret iz gore pomenutih razloga. Dodatnu validaciju Oauth vrši samo na osnovu kombinacije client_id i redirect_uri koje ima registrovane u bazi.
- redirect_uri – uri na koji će oauth nakon autorizacije redirektati korisnički browser i isporučiti token u URL-u.
- scope – opseg ovlasti koje se zahtijevaju prilikom autorizacije
- state – generisani pseudorandom string namijenjen za sprječavanje CSRF napada
Nakon što korisnik, kroz UI Oauth servera, autorizira se, potvrdi i da saglasnost, Oauth generiše token, a zatim kao response, redirekta korisnički browser na proslijeđeni redirect_uri:
HTTP/1.1 302 Found Location: http://our-app.com/callback#access_token=2YotnFZFEjr1zCsicMWpAA &state=xljfef209wu0939&token_type=Bearer&expires_in=3600
Obratite pažnju da je token isporučen u sklopu redirect URL-a kao fragment, odvojen hashom (#). Na samoj klijentskoj browser app (scripti) je da parsa URL i izdvoji token.
Bitno je napomenuti da se token u ovom slučaju obično može vidjeti od strane resource ownera (korisnika) u adress baru agenta (browsera). Ukoliko maliciozna aplikacija/skripta ima pristup browseru, može potencijalno doći do tokena. Takođe, browser obično čuva povijest surfanja, tako da token ostaje i u listi posjećenih URL-ova u history sekciji browsera. Sve to su sa stanovišta sigurnosti nepoželjne stvari.
Razlog zašto implicit grant ne predvidja niti dozvoljava upotrebu i izdavanje refresh tokena je također sigurnosni – kako se ne bi potencijalnom napadaču, u slučaju da i kompromitira token, dao dugotrajniji pristup kakav omogućava korištenje refresh tokena.
Umjesto toga, za implicit grant, u slučaju da aplikacija želi da “osvježi” token koji je istekao, mora proći kroz cijeli proces iz početka. Eventualno, da bi sve bilo transparentno i bezbolno za korisnika, neki Oauth provideri omogućavaju iskorištavanje već ostvarene sesiju (cookies i sl.), što olakšava resource owneru (korisniku) u smislu da se ne mora ponovno prijavljivati na autorizacijski server. To nije vezano za sam standard, već konkretnu implementaciju Oauth servera.
To je ukratko bio opis Implicit Grant-a, sa osnovnim koracima, razlozima za korištenje i nedostacima. Naredni post će detaljnije poređenje Implicit, Authorization Code i Authorization Code Grant sa PKCE – kada i za šta (ne) koristiti svaki ovaj flow.
Foto: Shutterstock