Kaj je OAuth: Pooblastitev brez deljenja gesla

Ste se kdaj prijavili v spletno aplikacijo preko Google, Facebook ali GitHub računa? Če da, ste že uporabili OAuth. OAuth je odprti standard za pooblastitev, ki omogoča aplikacijam dostop do uporabniških podatkov na drugi storitvi — brez da bi uporabnik razkril svoje geslo.

Kaj je OAuth?

OAuth 2.0 je okvir za pooblastitev (authorization framework), ki omogoča aplikaciji tretje osebe, da pridobi omejen dostop do uporabniškega računa na drugi storitvi. Namesto da bi uporabnik vnesel svoje geslo v aplikacijo tretje osebe, OAuth uporabi žetone (tokens), ki določajo, do katerih podatkov ima aplikacija dostop in za kako dolgo.

Primer iz vsakdanjega življenja: Predstavljajte si, da greste v hotel. Namesto da bi recepcijskemu uslužbencu dali ključ od svojega doma, prejmete kartico za dostop do hotelske sobe. Kartica omogoča dostop samo do določenih prostorov in preneha veljati ob odjavi. OAuth deluje podobno — aplikacija dobi žeton za dostop do določenih podatkov, ne pa gesla.

Zakaj je OAuth nastal?

Pred OAuth-om je bila pogosta praksa, da so aplikacije tretjih oseb zahtevale uporabniško ime in geslo za dostop do storitev, kot so Gmail ali Twitter. To je pomenilo več resnih varnostnih težav:

1. Izpostavljenost gesel: Aplikacija tretje osebe je videla in shranjevala uporabnikovo geslo v izvorni obliki
2. Preširoka dovoljenja: Aplikacija je dobila poln dostop do računa, ne samo do podatkov, ki jih je potrebovala
3. Težko preklicovanje: Edini način za preklic dostopa je bila sprememba gesla
4. Kompromitacija: Če je bila aplikacija tretje osebe vdrla, so bila gesla uporabnikov ogrožena

OAuth 2.0 je bil objavljen leta 2012 in rešuje vse te težave z uvajanjem žetonov in omejenih dovoljenj (scopes).

Ključni pojmi

Za razumevanje OAuth-a je treba poznati štiri glavne vloge:

Poleg vlog so pomembni še naslednji pojmi:

1. Access Token: Žeton, ki aplikaciji omogoča dostop do določenih podatkov. Ima omejeno veljavnost
2. Refresh Token: Žeton za obnovitev access token-a, ko ta poteče. Uporabnik se ne mora ponovno prijaviti
3. Scope: Določa, do katerih podatkov ima aplikacija dostop (npr. samo branje profila, ne pa pošiljanje e-pošte)
4. Authorization Code: Začasna koda, ki jo odjemalec prejme in jo zamenja za access token
5. Redirect URI: URL, na katerega je uporabnik preusmerjen po uspešni prijavi

Potek OAuth 2.0 (Authorization Code Flow)

Najpogostejši tip OAuth poteka je Authorization Code Flow, ki se uporablja pri spletnih aplikacijah. Tukaj je korak za korakom:

Tipi potekov (Grant Types)

OAuth 2.0 podpira več različnih potekov, odvisno od tipa aplikacije:

Primer registracije aplikacije

Da lahko aplikacija uporablja OAuth, se mora najprej registrirati pri ponudniku storitve (npr. Google, GitHub, Facebook). Pri registraciji dobi:

# Primer podatkov, ki jih aplikacija prejme pri registraciji

Client ID: 123456789012-abcdefghijklmnopqrstuvwxyz.apps.googleusercontent.com
Client Secret: GOCSPX-abCdEfGhIjKlMnOpQrStUvWxYz

# Redirect URI (kam se vrne uporabnik po prijavi)
Redirect URI: https://vadnica.org/auth/callback

# Scopes (dovoljenja, ki jih aplikacija zahteva)
Scopes:
  - openid # Za avtentikacijo (OpenID Connect)
  - profile # Branje osnovnih podatkov profila
  - email # Branje e-poštnega naslova

Client Secret je tajni ključ aplikacije in mora biti shranjen varno — nikoli ne sme biti izpostavljen v klientni strani kode (JavaScript v brskalniku).

OAuth 2.0 vs. OpenID Connect

To je pogosta zmeda, ki jo je treba razjasniti:

Preprosto rečeno: OAuth 2.0 reši vprašanje pooblastitve (ali lahko aplikacija bere vaše stike), OpenID Connect pa reši vprašanje avtentikacije (ali ste res vi). Večina sodobnih prijav "Login with Google" uporablja obe skupaj.

Najpogostejše varnostne napake

1. Nepravilna validacija redirect URI: Če strežnik ne preverja redirect URI-ja natančno, lahko napadalec preusmeri authorization code na svoj strežnik
2. Izpostavljen Client Secret: Če se Client Secret nahaja v JavaScript kodi na strani odjemalca, ga lahko napadalec izkoristi
3. Preširoki scopes: Zahtevanje več dovoljenj, kot jih aplikacija potrebuje, krši načelo najmanjših pravic
4. Neuporaba PKCE: Pri mobilnih in SPA aplikacijah je PKCE obvezen — brez njega je potek ranljiv na prisvzemanje kode
5. Nepravilno shranjevanje žetonov: Access token-i morajo biti shranjeni varno in nikoli v lokalni shrambi brskalnika (localStorage)

OAuth 2.1 — prihodnost

OAuth 2.1 je najnovejša različica, ki združuje najboljše prakse in odstranjuje zastarele metode. Glavne spremembe:

1. PKCE je obvezen za vse poteke z avtorizacijsko kodo
2. Implicit flow je popolnoma odstranjen
3. Password Credentials flow je odstranjen
4. Bearer token-i imajo striktna pravila za uporabo

Cilj OAuth 2.1 je poenostaviti implementacijo in odstraniti variante, ki so se izkazale za nevarne ali prekomerno zapletene.

Zakaj uporabljati OAuth?

OAuth je postal standard za varno pooblastitev v sodobnih spletnih in mobilnih aplikacijah. Njegove glavne prednosti so:

1. Brez deljenja gesel: Uporabnik nikoli ne vnese gesla v aplikacijo tretje osebe
2. Omejen dostop: Aplikacija dobi dostop samo do podatkov, ki jih potrebuje
3. Enostavno preklicovanje: Uporabnik lahko kadar koli prekliče dovoljenje v nastavitvah svojega računa
4. Boljša uporabniška izkušnja: Prijava z enim klikom brez ponovnega ustvarjanja računa
5. Standardizacija: Enak protokol podpirajo Google, Microsoft, GitHub, Facebook in številni drugi

V svetu, kjer so podatkovne kršitve vsakdanji pojav, OAuth ponuja varen način za izmenjavo podatkov med aplikacijami — brez tveganja izpostavljenosti gesel. Vsak razvijalec, ki gradi aplikacijo z uporabniškimi prijavami, bi moral razumeti osnove OAuth 2.0.