Ilustrirani vodič za OAuth i OpenID Connect

Napomena za prijevod.: Ovaj sjajan materijal tvrtke Okta jednostavno i slikovito objašnjava principe rada OAuth-a i OIDC-a (OpenID Connect). Ova znanja bit će korisna programerima, sistemskim administratorima pa čak i "običnim korisnicima" popularnih web aplikacija koji vjerojatno također razmjenjuju povjerljive podatke s drugim servisima.

U "kameno doba" interneta dijeljenje informacija između servisa bilo je lako. Jednostavno biste dali svoj korisnički ID i lozinku od jednog servisa drugom, kako bi se prijavio u vaš račun i dobio sve potrebne informacije.

"Dajte nam svoju bankovnu računicu." — "Obećavamo, s lozinkom i novcem bit će sve u redu. Stvarno, iskreno!" *hi-hi*

Užas! Nitko i nikada ne smije zahtijevati od korisnika da podijeli svoj korisnički ID i lozinku, svoje podatke, s drugim servisom. Nema nikakve garancije da organizacija koja stoji iza tog servisa čuva podatke na siguran način i ne prikupi više osobnih informacija nego što je potrebno. To može zvučati nevjerojatno, ali neke aplikacije i dalje primjenjuju sličnu praksu!

Danas postoji jedinstveni standard koji omogućuje jednom servisu sigurno korištenje podataka drugog. Nažalost, takvi standardi koriste hrpu žargonizama i termina, što otežava njihovo razumijevanje. Cilj ovog materijala je jednostavnim ilustracijama objasniti kako funkcioniraju (Mislite da moji crteži sliču dječjem crtanju? Pa i to je u redu!).

Usput, ovaj vodič također je dostupan u video formatu:

Dame i gospodo, upoznajte: OAuth 2.0

OAuth 2.0 je sigurnosni standard koji omogućuje jednoj aplikaciji da dobije dopuštenje za pristup informacijama u drugoj aplikaciji. Sekvenca radnji za izdavanje dopuštenja [permission] (ili pristanka [consent]) često se naziva autorizacijom [authorization] ili čak delegiranom autorizacijom [delegated authorization]. Pomoću ovog standarda dopuštate aplikaciji da proučava podatke ili koristi funkcije druge aplikacije u vaše ime, bez da joj otkrijete svoju lozinku. Sjajno!

Kao primjer, zamislite da ste otkrili stranicu naziva "Užasna igra riječima dana" [Terrible Pun of the Day] i odlučili ste se registrirati kako biste svakodnevno primali igre riječi u obliku tekstualnih poruka na telefon. Sviđa vam se stranica i odlučili ste je podijeliti sa svima koje poznajete. Na kraju krajeva, svi vole sljedeće igre riječi, zar ne?

«Neuspješna igra riječi dana: Jeste li čuli za dečka koji je izgubio lijevu polovicu tijela? Sada uvijek ima desnu!» (prijevod je okviran, jer u originalu postoji vlastita igra riječi — nap. prev.)

Razumljivo je da nije opcija pisati svakoj osobi s vaše kontakt liste. Ako ste samo malo slični meni, učinit ćete sve da izbjegnete dodatni trud. Srećom, Terrible Pun of the Day može sam pozvati sve vaše prijatelje! Sve što trebate učiniti je omogućiti mu pristup vašoj e-pošti kontakata — stranica će sama poslati pozivnice (OAuth je zakon)!

«Svi vole igre riječi! — Jeste li se već prijavili? — Želite li otvoriti pristup stranici Terrible Pun of the Day vašem popisu kontakata? — Hvala! Sada ćemo svakodnevno slati podsjetnike svima koje poznajete, do vječnosti! Vi ste najbolji prijatelj!»

1. Odaberite svoju uslugu e-pošte.
2. Po potrebi otvorite stranicu e-pošte i prijavite se na račun.
3. Dajte dopuštenje stranici Terrible Pun of the Day za pristup kontaktima.
4. Vratite se na stranicu Terrible Pun of the Day.

U slučaju da promijenite mišljenje, aplikacije koje koriste OAuth također nude način za poništavanje pristupa. Ako odlučite da više ne želite dijeliti kontakte s Terrible Pun of the Day, možete otići na stranicu e-pošte i ukloniti stranicu s igrama riječi s popisa ovlaštenih aplikacija.

OAuth protokol

Upravo smo prošli kroz ono što obično nazivamo protok [flow] OAuth. U našem primjeru, ovaj protok sastoji se od vidljivih koraka, kao i nekoliko nevidljivih koraka, u kojima se dva servisa dogovaraju o sigurnoj razmjeni informacija. U prethodnom primjeru s Terrible Pun of the Day koristi se najčešći OAuth 2.0 protokol, poznat kao protokol «s autorizacijskim kodom» [„authorization code“ flow].

Prije nego što se upustimo u detalje o radu OAuth-a, razgovarajmo o značenju nekih termina:

• Vlasnik resursa:

  
  
  To ste vi! Vi posjedujete svoje podatke, svoje vjerodajnice i upravljate svim radnjama koje se mogu izvršiti s vašim računima.

• Klijent:

  
  
  Aplikacija (na primjer, usluga Terrible Pun of the Day) koja želi pristupiti ili izvršiti određene radnje u ime Vlasnik resursakorisnika.

• Autorizacijski poslužitelj:

  
  
  Aplikacija koja zna Vlasnik resursatko je korisnik i u kojoj Vlasnik resursaima već korisnički račun.

• Resursni poslužitelj:

  
  
  Sučelje aplikacije (API) ili usluga koju Klijent želi iskoristiti u ime Vlasnik resursakorisnika.

• URI za preusmjeravanje:

  
  
  Veza na koju će Autorizacijski poslužitelj preusmjeriti Vlasnik resursakorisnika nakon što se odobri Klijentpristup. Ponekad se naziva i "Povratna URL adresa".

• Tip odgovora:

  
  
  Vrsta informacija koju očekuje dobiti Klijent. Najčešći Tip odgovoratip je kod, odnosno Klijent predviđa da će dobiti Autorizacijski kod.

• Opseg:

  
  
  Ovo je detaljan opis dozvola koje su potrebne Klijentkorisniku, kao što su pristup podacima ili izvršavanje određenih radnji.

• Suglasnost:

  
  
  Autorizacijski poslužitelj prikuplja Opsegekoji se traže Klijentod korisnika i pita Vlasnik resursakorisnika da li je spreman dati Klijentkorisniku odgovarajuće dozvole.

• Client ID:

  
  
  Ovaj ID se koristi za identifikaciju Klijentkorisnika na Autorizacijski poslužiteljposlužitelju.

• Tajna klijenta:

  
  
  Ovo je lozinka koja je poznata samo Klijentkorisniku i Autorizacijski poslužiteljposlužitelju. Omogućava im povjerljivu razmjenu informacija.

• Autorizacijski kod:

  
  
  Privremeni kod s kratkim razdobljem valjanosti koji Klijent pruža Autorizacijski poslužiteljkorisnik dobiva u zamjenu za Pristupni token.

• Pristupni token:

  
  
  Ključ koji će klijent koristiti za komunikaciju sa Resursni poslužiteljresursnim poslužiteljem. Ova vrsta oznake ili ključa omogućava Klijentkorisniku pristup podacima ili izvršavanje radnji na Resursni poslužiteljposlužitelju u vaše ime.

Napomena: ponekad su Autorizacijski poslužitelj i Resursni poslužitelj isti poslužitelj. Međutim, u nekim slučajevima to mogu biti različiti poslužitelji, čak i oni koji ne pripadaju istoj organizaciji. Na primjer, Autorizacijski poslužitelj može biti usluga treće strane kojoj vjeruje Resursni poslužitelj.

Sada kada smo se upoznali s osnovnim pojmovima OAuth 2.0, vratimo se našem primjeru i detaljno razmotrimo što se događa u OAuth toku.

1. Želite pružiti usluzi Terrible Pun of the Day ( Vlasnik resursakorisniku) pristup vašim kontaktima kako bi mogla poslati pozivnice svim vašim prijateljima.KlijentPreusmjerava preglednik na stranicu
2. Klijent korisnika i uključuje u zahtjev Autorizacijski poslužiteljjednu ili više Client ID, URI za preusmjeravanje, Tip odgovora dozvola koje su mu potrebne. Opsege provjerava vas, zahtijevajući po potrebi prijavu i lozinku.
3. Autorizacijski poslužitelj izlaže obrazac
4. Autorizacijski poslužitelj potvrde s popisom svih Suglasnost dozvola koje se traže Opsegeod korisnika. Slažete se ili odbijate. KlijentPreusmjerava vas na web stranicu
5. Autorizacijski poslužitelj korisnika, koristeći Klijentzajedno s URI za preusmjeravanje (autorizacijskim kodom). Autorizacijski kod Direktno se povezuje s
6. Klijent korisnikom (izravno bez preglednika Autorizacijski poslužitelj‘ом (в обход браузера Vlasnik resursa‘a) i sigurno šalje Client ID, Tajna klijenta i Autorizacijski kod.
7. Autorizacijski poslužitelj provjerava podatke i odgovara s Pristupni token‘om (pristupnom tokenom).
8. Sada Klijent može koristiti Pristupni token za slanje zahtjeva na Resursni poslužitelj s ciljem dobivanja popisa kontakata.

Client ID i Secret

Dugo prije nego što ste dopustili Terrible Pun of the Day pristup kontaktima, Client i Authorization Server su uspostavili radne odnose. Authorization Server je generirao Client ID i Client Secret (ponekad ih nazivaju App ID i App Secret) i poslao ih Clientu za daljnju interakciju unutar OAuth-a.

«— Bok! Htio bih raditi s tobom! — Nema problema! Evo tvojih Client ID i Secret!»

Naziv sugerira da Client Secret treba ostati tajna, tako da ga znaju samo Client i Authorization Server. Na kraju krajeva, upravo uz njegovu pomoć Authorization Server potvrđuje istinitost Client-a.

Ali to nije sve… Molimo pozdravite OpenID Connect!

OAuth 2.0 je dizajniran samo za ovlaštenje — za pružanje pristupa podacima i funkcijama s jedne aplikacije na drugu. OpenID Connect (OIDC) je tanki sloj iznad OAuth 2.0 koji dodaje informacije o prijavi i profilu korisnika koji je prijavljen. Organizaciju sesije prijave često nazivamo autentifikacijom [authentication], a informacije o korisniku koji je prijavljen (tj. o Vlasnik resursa‘e), — osobnim podacima [identity]. Ako Authorization Server podržava OIDC, ponekad ga nazivamo dobavljačem osobnih podataka [identity provider], jer on pruža Klijent‘u informacije o Vlasnik resursaposlužitelju.

OpenID Connect omogućuje ostvarenje scenarija u kojima se jedan način prijave može koristiti u više aplikacija — ovaj pristup je također poznat kao single sign-on (SSO). Na primjer, aplikacija može podržavati SSO integraciju s društvenim mrežama kao što su Facebook ili Twitter, omogućavajući korisnicima da koriste račun koji već imaju i koji preferiraju koristiti.

Tijek (flow) OpenID Connect izgleda isto kao i kod OAuth-a. Jedina razlika je u tome što je u prvotnom zahtjevu korišteni specifični scope — openid, — a Klijent na kraju dobiva kao Pristupni token, kao i ID Token..

Kao i u toku OAuth-a, Pristupni token u OpenID Connect — ovo je neki vrijednost, nepoznata Klijent‘u. Iz perspektive Klijent‘a Pristupni token predstavlja neku stringu znakova koja se šalje s svakim zahtjevom prema Resursni poslužitelj‘u, a on određuje je li token važeći. ID Token. predstavlja posve drugo.

ID Token je JWT

ID Token. — to je posebno formatirana stringa znakova, poznata kao JSON Web Token ili JWT. (ponekad se JWT tokeni izgovaraju kao «jots»). Vanjskim posmatračima, JWT može izgledati kao nerazumljiva abeceda, međutim Klijent može izvući razne informacije iz JWT-a, kao što su ID, korisničko ime, vreme prijavljivanja, rok važenja ID Token.‘a, prisutnost pokušaja ometanja JWT-a. Podaci unutar ID Token.‘a nazivaju se izjavama [claims].

U slučaju OIDC-a postoji standardni način na koji Klijent može zatražiti dodatne informacije o identitetu [identity] od Autorizacijski poslužitelj‘a, na primer, adresu elektronske pošte, koristeći Pristupni token.

Dodatne informacije o OAuth-u i OIDC-u

Dakle, ukratko smo razmotrili principe rada OAuth-a i OIDC-a. Spremni za dublje istraživanje? Evo dodatnih resursa koji će vam pomoći da saznate više o OAuth 2.0 i OpenID Connect:

• Šta je OAuth?
• Niko se ne brine o OAuth-u ili OpenID Connect-u
• Implementirajte OAuth 2.0 autorizacijski kod s PKCE tokom
• Šta je OAuth 2.0 tip odobrenja?
• OAuth 2.0 iz komandne linije
• Izgradite sigurnu Node.js aplikaciju sa SQL Serverom

Kao i obično, slobodno ostavite komentare. Da biste bili u toku s našim poslednjim novinama, pretplatite se na Twitter i YouTube kompaniju Okta za programere!

P.S. od prevodioca

Pročitajte i na našem blogu:

• «Abeceda sigurnosti u Kubernetesu: autentifikacija, autorizacija, revizija»;
• «Korisnici i autorizacija RBAC-a u Kubernetesu»;
• «33+ alata za sigurnost Kubernetesa»;
• «Sigurnost za Docker kontejnere».

Izvor: habr.com