OAuth 2.0

OAuth 2.0 je autorizacijski okvir koji jednoj aplikaciji omogućuje ograničeni pristup resursima druge aplikacije u ime korisnika — bez da ikada vidi korisničku lozinku. Klasičan slučaj upotrebe: aplikacija kalendara koja treba čitati vaš Google kalendar ne bi trebala zahtijevati da joj date svoju Google lozinku. OAuth vam omogućuje da umjesto toga aplikaciji dodijelite ograničeni token koji se može opozvati.

Glumci

Četiri uloge u toku OAuth:

• Vlasnik resursa — vi, korisnik s podacima negdje
• Klijent — aplikacija koja želi pristup (npr. preglednik kalendara treće strane)
• Autorizacijski poslužitelj — usluga koja vas autentificira i izdaje tokene (npr. Googleova krajnja točka OAuth)
• Poslužitelj resursa — API koji čuva vaše podatke (npr. Google Calendar API)

Protok autorizacijskog koda

Standardni tijek na strani poslužitelja, pojednostavljeno:

1. Kliknete "Poveži Google kalendar" u aplikaciji klijenta.
2. Klijent preusmjerava vaš preglednik na Googleov poslužitelj autorizacije s parametrima: client_id, redirect_uri, opseg (calendar.read), stanje (CSRF token).
3. Autentificirate se Googleu ako već niste prijavljeni.
4. Google vam prikazuje zaslon pristanka: "CalendarViewer želi čitati vaš kalendar. Dopustiti?"
5. Kliknete Dopusti. Google preusmjerava vaš preglednik natrag na klijentov redirect_uri s jednokratnim autorizacijskim kodom.
6. Klijentov kôd na strani poslužitelja razmjenjuje autorizacijski kod (plus svoju klijentsku tajnu) za pristupni token izravnim pozivanjem Googleove krajnje točke tokena.
7. Klijent koristi pristupni token za pozivanje Google Calendar API-ja u vaše ime.
8. Kada pristupni token istekne (obično jedan sat), klijent koristi token za osvježavanje kako bi dobio novi bez da vam smeta.

Ključno sigurnosno svojstvo: vaša lozinka nikada ne dodiruje klijentsku aplikaciju. Klijent dobiva označeni token koji možete opozvati na Googleovoj nadzornoj ploči računa bilo kada.

OAuth 2.0 naspram OAuth 2.1 naspram OIDC

• OAuth 2.0 je standard iz 2012. (RFC 6749). Od tada je dodano nekoliko RFC-ova proširenja i dokumenata o najboljoj praksi.
• OAuth 2.1 (u nacrtu od 2026.) objedinjuje trenutne najbolje prakse u jednu specifikaciju — obavezan PKCE, uklonjen Implicit Flow, itd.
• OpenID Connect (OIDC) sloj je identiteta povrh OAutha 2.0. Sam OAuth daje neprozirni pristupni token; OIDC dodaje ID token (JWT) koji autentificira korisnika. Većina gumba "Prijavi se pomoću..." koristi OIDC, a ne obični OAuth.

Vrste odobrenja

OAuth 2.0 definira nekoliko tokova za različite scenarije:

• Autorizacijski kod — standardni tijek na strani poslužitelja opisan gore. S proširenjem PKCE, također ga koriste mobilne i SPA aplikacije.
• Implicitni tok (zastarjelo) — izdani pristupni tokeni izravno putem fragmenta URL-a. Osjetljivo na curenje tokena; zamijenjen autorizacijskim kodom + PKCE.
• Resource Owner Password Credentials (rijetko se koristi) — klijent prikuplja korisničku lozinku i mijenja je za token. Trebalo bi se koristiti samo u naslijeđenim scenarijima migracije.
• Klijentske vjerodajnice — za stroj-stroj gdje nema korisnika. Klijent se autentificira i dobiva token za vlastite resurse.
• Šifra uređaja — za uređaje bez preglednika (TV, IoT). Uređaj prikazuje kod; korisnik autorizira s telefona ili prijenosnog računala.
• Token za osvježavanje — mijenja dugotrajni token za osvježavanje za svježi token za pristup bez interakcije korisnika.

PKCE: proširenje koje morate imati

PKCE (Proof Key za Code Exchange, izgovara se "pixie") sprječava napade presretanja autorizacijskog koda. Klijent generira slučajnu tajnu, hashira je i šalje hash u zahtjevu za autorizaciju. Prilikom razmjene koda šalje izvornu tajnu. Poslužitelj za autorizaciju provjerava podudaranja hash vrijednosti. Svaki napadač koji presretne kod ne može ga razmijeniti bez originalne tajne.

PKCE sada se smatra obaveznim za sve OAuth klijente — javne (preglednik, mobilni) i povjerljive (na strani poslužitelja).

Opsezi

Tokeni se izdaju s određenim opsegom — radnjama koje smiju izvoditi. Googleovi tipični dometi izgledaju kao https://www.googleapis.com/auth/calendar.readonly. Klijent zahtijeva opsege; korisnik ih vidi na zaslonu pristanka i odobrava ili odbija. Načelo najmanje privilegije: tražite samo opsege koji su vam stvarno potrebni.

Uobičajeni OAuth napadi

• Otvoreno preusmjeravanje. Pogrešno konfiguriran parametar redirect_uri omogućuje napadaču preusmjeravanje autorizacijskog koda na vlastiti poslužitelj.
• State parametar propust. Bez vrijednosti stanja povezane s korisničkom sesijom, OAuth tokovi ranjivi su na CSRF — napadač prevari žrtvu da dovrši OAuth tijek koji povezuje napadačev račun sa žrtvinom sesijom.
• Curenje tokena u povijesti preglednika (glavni Implicitni tok slabost).
• Krađa tokena putem XSS-a. Ako klijentska aplikacija pohranjuje tokene u localStorage i ima bilo kakvu XSS ranjivost, napadači ih mogu ukrasti.
• Phishing zaslona pristanka. Napadač registrira zlonamjernog OAuth klijenta koji traži osjetljive opsege; korisnik, uvjetovan da klikne "Dopusti" na zaslonima pristanka, odobrava pristup bez nadzora.

Što učiniti kao korisnik

• Povremeno pregledajte povezane aplikacije na postavkama Google/Apple/Microsoft/Facebook/GitHub računa. Opozovite one koje ne koristite.
• Pročitajte opsege zaslona pristanka prije odobravanja pristupa. "Upravljaj svojim kalendarom" razlikuje se od "Prikaži svoj kalendar."
• Budite skeptični prema OAuth zahtjevima iz aplikacija koje ne prepoznajete, čak i ako se pojave tijekom poznatog tijeka rada.