Autentikacijski protokol OpenID Connect (OIDC) u sustavu AAI@EduHr

Sustav AAI@EduHr je autentikacijska i autorizacijska infrastruktura sustava znanosti i visokog obrazovanja u Republici Hrvatskoj. Temelji se na sustavu imenika u kojima su pohranjeni elektronički identiteti korisnika. Pojedine imenike održavaju ustanove iz sustava znanosti i obrazovanja dodjeljujući elektroničke identitete svojim studentima, djelatnicima i suradnicima. Prilikom dodjele elektroničkog identiteta svaki korisnik dobiva vjerodajnice (korisničku oznaku i zaporku) koje koristi prilikom prijave za korištenje usluga koje se oslanjaju na sustav AAI@EduHr za autentikaciju i autorizaciju.

Korištenjem sustava AAI@EduHr omogućuje se jedinstvena autentikacija korisnika (Single Sign-On − SSO), odnosno omogućuje se da se korisnik u sustav AAI@EduHr prijavi samo jednom i nakon toga pristupa svim aplikacijama koje koriste SSO servis bez potrebe za ponovnim unosom vjerodajnica. Uporaba Single Sign-On servisa znatno poboljšava doživljaj korisnika prilikom prijavljivanja u veći broj aplikacija.

Postupak autentikacije započinje korisnik unosom vjerodajnica, nakon čega se provodi njihova provjera u imeniku odgovarajuće ustanove te slanje informacija o korisniku usluzi u koju se korisnik želi prijaviti. Kako bi se čitav postupak proveo na siguran način, sustav AAI@EduHr koristi standardne autentikacijske protokole. Od samog početka rada sustava AAI@EduHr (2006. godine) podržan je autentikacijski protokol Security Assertion Markup Language (SAML), trenutno u verziji 2.0, a od 2010. godine podržan je i protokol Central Authentication Service (CAS). Većina usluga trenutno koristi protokol SAML, i zbog dulje podrške od strane sustava AAI@EduHr i zbog njegove popularnosti u akademskoj zajednici na europskoj i svjetskoj razini. No zbog rasta popularnosti novijeg autentikacijskog protokola sustav AAI@EduHr u prosincu 2020. godine nadograđen je mogućnošću korištenja protokola OpenID Connect (OIDC).

Kao SAML i CAS, OIDC također omogućuje sigurnu autentikaciju i razmjenu korisničkih podataka između davatelja identiteta (matične ustanove) i same usluge koju korisnik želi koristiti, no to čini na drugačiji način. OIDC je temeljen na protokolu OAuth 2.0 i koristi HTTPS/JSON tijekove za prijenos poruka, što ga čini jednostavnijim za implementaciju u usporedbi s protokolima poput SAML-a. Dizajniran je tako da ga je moguće koristiti u svim tipovima klijentskih aplikacija uključujući JavaScript aplikacije (aplikacije koje se izvršavaju samo u pregledniku) te u izvornim aplikacijama (npr. Android, iOS).

Povijest obitelji protokola OpenID i problem interoperabilnosti

OpenID Connect treća je generacija OpenID tehnologija. Prve dvije verzije protokola bile su OpenID 1.0 te OpenID 2.0, a obje verzije nikad nisu stekle veću popularnost. Neki od razloga za to je bili su problematična implementacija u izvornim aplikacijama te oslanjanje na format poruka u XML-u s nestandardnim algoritmom za potpisivanje poruka.

U protokolu OpenID Connect riješeni su spomenuti problemi koristeći naširoko prihvaćene standarde, na razini oblikovanja autentikacijskih poruka, samih podataka, algoritama za šifriranje ili potpisivanja poruka te na kraju u obavljanju čitavog autentikacijskog tijeka.

Činjenica da je OpenID Connect baziran na standardnim bazičnim sigurnosnim elementima autentikacije i autorizacije čini sam protokol ineroperabilnijim i lakšim za implementaciju. Na primjer, čitav autentikacijski tijek zapravo je baziran na vrlo popularnom autorizacijskom protokolu OAuth2, koji određuje da sav promet prema autorizacijskom serveru mora biti zaštićen TLS-om (dakle, mora se koristiti HTTPS − HTTP Secure). Za prijenos korisničkih podataka koristi standardne JSON Web Token strukturirane podatke te poznate i dobro dokumentirane algoritme za potpisivanje i šifriranje (kriptiranje) samih tokena.

Dakle, da bi developer mogao implementirati protokol OpenID Connect, sve što mora znati su osnove HTTP protokola, poznavati način formatiranja podataka u JSON-u, osnove kodiranja podataka (prebacivanje podataka iz jednog formata u drugi), osnove funkcija za raspršivanje (engl. hashing functions) te osnovne koncepte kriptografije (bilo korištenje para javnog i privatnog ključa za asimetričnu kriptografiju ili korištenje tajnog ključa za simetričnu kriptografiju).

No, zbog velike popularnosti protokola OpenID Connect i postojanja već mnogih OIDC klijenata u otvorenom pristupu na različitim platformama i u različitim programskim jezicima, često je dovoljno iskoristiti postojeći klijent na način da mu se daju specifični parametri okruženja u kojem se autentikacija implementira i to je to.

Osnovni elementi sustava AAI@EduHr i njihovo međudjelovanje

Da bi se stekla cjelokupna slika, prođimo ukratko osnovne elemente sustava AAI@EduHr:

• Elektronički identitet
  
  • skup podataka (atributa) o pojedincu koji se koristi za potrebe provjere identiteta (autentikacija) i prava pristupa (autorizacija)
• Matične ustanove
  
  • davatelji elektroničkih identiteta
  • npr. sveučilišta, fakulteti, visoke škole, škole
• Krajnji korisnici
  
  • vlasnici elektroničkog identiteta
  • npr. profesori, studenti, učenici, zaposlenici u ustanovi
• Davatelji usluga (resursa)
  
  • matične ustanove ili partneri AAI@EduHr
  • daju usluge kroz (web) aplikacije na koje se krajnji korisnici mogu autenticirati svojim elektroničkim identitetom
• Središnji AAI@EduHr servisi
  
  • posrednički sustav između korisnika, usluge i matične ustanove koji se koristi prilikom postupka autentikacije

Da bismo razumjeli kako ti osnovni elementi međudjeluju, pogledajmo primjer pojednostavljenog autentikacijskog tijeka:

Video 1. Pojednostavljen autentikacijski tijek

Opis tijeka:

1. Korisnik pristupi usluzi (pokuša se prijaviti)
2. Usluga preusmjeri korisnika na autentikaciju na središnje AAI@EduHr servise
3. Na središnjim AAI@EduHr servisima korisnik unosi svoje vjerodajnice (nije bitno u kojem su obliku vjerodajnice, u smislu je li riječ o korisničkom imenu i lozinci, multifaktorskoj autentikaciji, autentikaciji pomoću certifikata itd.)
4. Središnji servis kontaktira AOSI web-servis (AOSI WS) na matičnoj ustanovi korisnika i obavlja autentikaciju pomoću danih vjerodajnica, čime se obavlja i dohvat atributa.
5. Ako je autentikacija uspješna, usluzi se vraća odgovor s informacijom o autentikaciji (npr. kada se autentikacija dogodila (timestamp), kojoj je usluzi odgovor namijenjen, potpis odgovora i druge slične sigurnosne informacije). Uz to, vraća i korisničke atribute, tj. podatke o korisniku koji se autenticirao.

Sustav jedinstvene autentikacije korisnika (engl. Single-Sign On − SSO)

Pojednostavljeni autentikacijski tijek jasno prikazuje na koji način središnji servisi sustava AAI@EduHr posreduju između krajnjeg korisnika, matične ustanove i usluge realizirane kao aplikacija prilikom postupka autentikacije. Uz samu ulogu posredovanja, sustav AAI@EduHr omogućuje i tzv. jedinstvenu autentikaciju korisnika (Single Sign-On − SSO), odnosno omogućuje da se korisnik u sustav AAI@EduHr prijavi samo jednom i nakon toga pristupa svim aplikacijama koje koriste SSO servis bez potrebe za ponovnim unosom vjerodajnica. Funkcionalnost SSO oslanja se na zapravo vrlo jednostavan princip − korištenje kolačića (engl. cookies) u web-preglednicima za održavanje  korisničke sjednice (engl. session). Zbog toga u SSO autentikaciji vrlo važnu ulogu ima korisnički agent (engl. User-Agent), tj. web-preglednik. Pogledajmo sljedeći dijagram:

Video 2. SSO autentikacijski tijek

Opis SSO tijeka.

• Oblak davatelja usluga odnosi se na više različitih usluga. Korisnik prvo pristupa jednoj usluzi (na kojoj nije lokalno prijavljen) koja ga preusmjerava na autentikaciju na AAI@EduHr središnje servise. Za to se koristi web-preglednik (engl. browser), neovisno o tome radi li se o web-aplikacijama ili izvornim (engl. native) aplikacijama (Android i iOS, na tim aplikacijama će se podignuti sistemski web-preglednik). Efektivno se šalje (određeni) HTTP GET zahtjev na određeni URL na središnjim servisima (u ovom trenutku nebitno kojem).
• Središnji servisi provjeravaju je li korisnik već autenticiran (u ovom slučaju nije) pa obavljaju preusmjeravanje na autentikaciju na određeni URL na središnjem servisima. Pritom se kreira i korisnička sjednica (session) te se postavlja SSO kolačić koji sadrži ID sjednice.
• Korisnik unosi vjerodajnice te se u pozadini koristi AOSI WS na korisnikovoj matičnoj ustanovi za autentikaciju i dohvat atributa. Po uspješnoj autentikaciji usluzi se vraćaju korisnički atributi.
• Kada korisnik pristupi drugoj usluzi na kojoj nije lokalno ulogiran, također se obavlja preusmjeravanje na središnje servise. Ovaj će put web-preglednik ujedno poslati i kolačić (cookie) koji sadrži ID SSO sjednice. Središnji servisi će provjeriti valjanost sjednice, dohvatiti korisničke podatke iz cachea te odmah vratiti odgovor usluzi.

Dakle, princip rada SSO-a prilično je jednostavan − zasniva se na standardnom funkcioniranju održavanja stanja između različitih HTTP zahtjeva pomoću kolačića u web-pregledniku.

Pregled protokola korištenih u sustavu AAI@EduHr

Kompleksnost u realizaciji autentikacijskih postupaka dolazi u trenutku potrebe implementacije protokola za prijenos informacija između različitih elemenata sustava.

AAI@EduHr koristi standardne protokole koji jamče interoperabilnost i sigurnost u komunikaciji između različitih elemenata. Tako je npr. povezan s nacionalnim sustavima NIAS i europskim sustavom eduGAIN pomoću protokola SAML. Komunikacija sa servisom AOSI WS obavlja se preko protokola SOAP, dok usluga eduram koristi protokol RADIUS. Na matičnoj ustanovi elektronički identiteti pohranjeni su u LDAP bazi, pa se shodno tome koristi i protokol LDAP za pristup korisničkim podacima.

Dio koji nas najviše zanima u ovom članku jest komunikaciju između davatelja usluga i središnjih servisa, a u tom dijelu mogu se koristiti tri protokola: SAML, CAS, OIDC.

Nazivi entiteta prema autentikacijskom protokolu

Davatelji usluga te dio sustava koji posreduje u autentikaciji (središnji servisi) u različitim autentikacijskim protokolima imaju različite nazive. U nastavku je tablica s pregledom naziva.

Za potrebe ovog članka najviše nas zanima nazivlje koje se koristi u protokolu OIDC. Dakle, po OIDC-u usluga je Relying Party (RP), dok su središnji servisi OpenID Provider (OP).

Uspostava povjerenja (na primjeru OIDC-a)

Prije nego se omogući razmjena autentikacijskih poruka između RP-a i OP-a, mora se uspostaviti povjerenje između tih dvaju entiteta.

Povjerenje se uspostavlja razmjenom (prihvaćanjem) međusobnih metapodataka.

U sustavu AAI@EduHr davatelj usluga (RP) će „javit će“ svoje metapodatke središnjim servisima (OpenID Provideru) na način da registrira uslugu u AAI@EduHr registru resursa.

Uz to, RP će preuzeti metapodatke od središnjih OIDC servisa (OpenID Providera − OP).

Nakon toga, po prihvaćanju registracije OIDC resursa davatelja usluge (nakon uspostavljenog povjerenja), omogućuje se slanje autentikacijskih odgovora na novoregistriranu OIDC uslugu.

Registracija OIDC resursa

Registracijom usluge u Registru resursa, tj. specifično OIDC resursa, definiraju se:

• Klijentske vjerodajnice (engl. Client ID, Secret). ID klijenta (engl. Client ID) definira AAI@EduHr i nepromjenjiv je. Tajni ključ (engl. Secret) također definira AAI@EduHr, ali se može resetirati.
• Lokacije za preusmjeravanje (engl. Redirect URIs), tj. URI na koji će se vratiti autentikacijski odgovor. Definira ih davatelj usluge.
• Tip klijenta (povjerljiv ili javan) − povjerljiv klijent jest onaj koji može na siguran način čuvati klijentske vjerodajnice (npr. web-aplikacije koje se izvršavaju na poslužitelju). Klijenti kao što su JavaScript aplikacije ili izvorne aplikacije javni su klijenti jer se smatra da se iz takvih aplikacija mogu izvući klijentske vjerodajnice
• Opsezi i tvrdnje (engl. Scopes and Claims) − koncept odabira korisničkih atributa. Bira ih davatelj usluge

Primjer ekrana registriranog OIDC resursa:

Metapodaci OpenID Providera (OP)

Metapodaci OP-a koji su dostupni na ovoj poveznici definiraju i opisuju osnovne funkcionalnosti autentikacijskog poslužitelja.

Podaci su formatirani kao JSON objekt, stoga on može poslužiti i programskom dohvatu i obradi pri određivanju podržanih funkcionalnosti iz samog protokola. Primjer sadržaja JSON-a:

Iz JSON-a vidimo:

• ID izdavatelja (engl. issuer): https://login.aaiedu.hr/
• krajnje točke (engl. endpoints) koje se koriste za autentikaciju krajnjeg korisnika − svojstva „authorization_endpoint“, „token_endpoint“ i „userinfo_endpoint“
• URL na JSON web-skup ključeva (engl. JSON Web Key Set − JWKS) pomoću kojih se može provjeravati potpis u ID tokenu − svojstvo „jwks_uri“
• podržani opsezi − svojstvo „scopes_supported“
• podržani autentikacijski tijekovi − svojstvo „response_types_supported“
• podržani tipovi identifikatora subjekta (engl. subject identifier) − svojstvo „subject_types_supported“
• podržani algoritmi za potpisivanje ID tokena − svojstvo „id_token_signing_alg_values_supported“
• podržane metode za generiranje parametra „code_challenge“ − svojstvo „code_challenge_methods_supported“

JSON web-skup ključeva (engl. JSON Web Key Set − JWKS)

Prethodno spomenuti OP metapodaci sadrže i polje „jwks_uri“ koje za vrijednost ima URL na JSON web-skup ključeva.

JWKS je JSON objekt koji pod svojstvom „keys“ sadrži polje ključeva, dakle jedan ili više ključeva u formatu JWK (JSON Web Key  JWK). To su ključevi među kojima će se nalaziti i onaj javni ključ koji se može koristiti za provjeru potpisa.

Primjer JWKS-a:

Iz JSON-a vidljivo je da se definiraju stvari kao što su:

• kty − tip ključa (u ovom slučaju RSA)
• kid − ID ključa
• use − namjena korištenja (u ovom slučaju „sig“, tj. za provjeru potpisa)
• alg - algoritam (u ovom slučaju RS256, tj. RSA SHA256)

Ostali parametri ovise o tipu ključa, a u ovom slučaju to su:

• n − modulo vrijednost javnog ključa (Base64Url encoded)
• e − eksponent javnog ključa (Base64Url encoded).

Namjena JWKS-a također je omogućavanje programskog dohvata javnog ključa te nakon toga  automatska provjera potpisa u autentikacijskom odgovoru pomoću dostupnog ključa.

Opsezi i tvrdnje

Opsezi definiraju koje će se tvrdnje o korisniku isporučivati RP-u, a tvrdnje su informacije o autentikacijskom događaju ili o autenticiranom korisniku. Svi dostupni opsezi navedeni su u OP metapodacima, a potrebni opsezi za RP-a definiraju se prilikom registracije OIDC resursa.

AAI@EduHr koristi tri vrste opsega i tvrdnji:

• standardne opsege i tvrdnje (definirano specifikacijom)
• AAI@EduHr opsege i tvrdnje
• stalne tvrdnje (informacije o autentikacijskom događaju).

Standardni opsezi i tvrdnje

U tablici dolje navedeni su standardni (oni propisani specifikacijom) opsezi i tvrdnje koje podržava AAI@EduHr. AAI@EduHr mapira određene standardne tvrdnje na AAI@EduHr korisničke atribute, ali ne sve (obično zbog drugačijeg formata ili jednostavno zbog nepostojanja podatka).

Opseg „openid“ specifičan je po tome što ne definira tvrdnje, nego definira isporuku ID tokena.

AAI@EduHr opsezi i tvrdnje

Specifikacija predviđa definiranje prilagođenih (engl. custom) opsega i tvrdnji, što je AAI@EduHr iskoristio za kreiranje svojih opsega. To je napravljeno zbog potrebe da se omogući isporuka svih korisničkih atributa iz AAI@EduHr hrEduPerson sheme (AAI@EduHr shema atributa).

AAI@EduHr opseg ima isti naziv kao i tvrdnja koju predstavlja, a tvrdnja ima isti naziv kao AAI@EduHr korisnički atribut definiran u AAI@EduHr shemi korisničkih atributa. Svaka AAI@EduHr tvrdnja će biti u obliku JSON polja (engl. array), neovisno o tome može li AAI@EduHr korisnički atribut kojeg predstavlja imati višestruke vrijednosti ili ne. Na primjer, odabirom opsega „uid“ isporučivat će se tvrdnja „uid“ (u obliku polja) koja će imati vrijednost AAI@EduHr korisničkog atributa „uid“.

Stalne tvrdnje

Prilikom isporuke podataka nakon autentikacije korisnika RP-u će se isporučiti i tvrdnje koje opisuju sam autentikacijski događaj:

ID token

Uz predefinirane opsege i tvrdnje, jedna od glavnih stvari koju protokol OpenID Connect donosi u odnosu na protokol OAuth2 je ID token. ID token je taj pomoću kojeg će se nakon autentikacijskog postupka RP-u dostaviti korisnički podaci i podaci o autentikacijskom događaju.

ID token realiziran je kao JWT (JSON Web Token), a primjer je:

eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsImtpZCI6IjY5ZDhjNDY1NzQifQ.eyJpc3MiOiJodHRwczovL2xvZ2
luLmFhaWVkdS5ociIsImF1ZCI6IjZlNTUyOTUyMDk3ODJiN2IyIiwianRpIjoiYzQ0ZjRjZmZjYzg0Zjc5OTBmN
2ExZDViMmMiLCJuYmYiOjE2MDI2NzQ0NzAsImV4cCI6MTYwMjY3NTA3MCwic3ViIjoiYmZhMTYwNWJ
lNDRhNTBhN2MiLCJpYXQiOjE2MDI2NzQ0NzAsIm5vbmNlIjoiZHRubWVCTDVIVm5oUWtJUiIsIm5hbWU
iOiJJdmFuIEhvcnZhdCIsImZhbWlseV9uYW1lIjoiSG9ydmF0IiwiZ2l2ZW5fbmFtZSI6Ikl2YW4iLCJwcmVmZ
XJyZWRfdXNlcm5hbWUiOiJpaG9ydmF0QHByaW1qZXIuaHIiLCJlbWFpbCI6Iml2YW4uaG9ydmF0QHBy
aW1qZXIuaHIiLCJockVkdVBlcnNvblVuaXF1ZU51bWJlciI6WyJMT0NBTF9OTzogMTIzNCIsIk9JQjogMTIz
NDU2Nzg5MTIiLCJKTUJBRzogMTIzNDU2Nzg5MSJdfQ.c5q4W3bmcxQepAHj9n7xxj8WaH0wqIaiFkOFB
9UE3joeVUyU9hWuNsDfPJ_BZ7WfYnhyMrv29Ys-dHs1oKqagvqFdk157IEwLnW1Dd5vNXvgGhMBhCTtse
eQBDFS_DHN6KaksFDnGtFyWh3GXq-dWEBO86fpgSB3OuV9CD-AQAAbjXsN4Mz9MyaajMkhxWgxh_
7HTZMlg5hACv3Xn-wiI8N3IGDqWrgdB87Vo6n0T5TfVaUZQ8mw5ca5fKy-aH5BP940LBb3bt6CvhZqxK0XF
mD_M8hh-2MyRuPf2u6_P9HUORo1f8x8ZI30J2arhghPRcqEK9Sv_hdPxMy7WJJupg

Svaki JWT (pa tako i ID token) sastoji se od triju dijelova odvojenih točkom:

• zaglavlje (engl. header)
• korisni podaci (engl. payload)
• potpis (engl. signature)

Zaglavlje i korisni podaci zapravo su JSON objekti, a svaki spomenuti dio je Base64 URL kodiran. Potpis je generiran nad kodiranim zaglavljem i korisnim podacima koristeći privatni ključ i algoritam naznačen u zaglavlju, također Base64 URL kodiran.

Postavlja se pitanje kako doći do spomenutih JSON-a zaglavlja i korisnih podataka? Postupak je jednostavan i može se podijeliti na sljedeće korake:

1. razdijeliti token na tri dijela po točki (na stringove zaglavlja, korisnih podataka i potpisa)
2. napraviti Base64 URL dekodiranje stringova zaglavlja i korisnih podataka
3. provjeriti potpis

U postupku kreiranja potpisa koristi se privatni ključ iz para javnog i privatnog RSA ključa. Za provjeru tog potpisa potrebno je iskoristiti javni ključ koji je dostupan u JSON web-skupu ključeva (JWKS URI). Odgovarajući javni ključ može se pronaći preko ID ključa („kid“) koji je naznačen u zaglavlju ID tokena te u pojedinom ključu u JSON web-skupu ključeva.

Primjer dekodiranih JSON-a:

Podržani autentikacijski tijekovi (engl. authentication flows)

Autentikacijski tijek se odnosi niz HTTP zahtjeva i preusmjeravanja (engl. redirections) između aplikacije (resursa) i autentikacijskog poslužitelja. Različiti autentikacijski tijekovi znače različit način slanja HTTP zahtjeva i različit način dohvata korisničkih podataka nakon autentikacije.

Trenutno podržani autentikacijski tijekovi su:

• Tijek autorizacijskog koda (engl. Authorization Code Flow) − OIDC ili OAuth2 tijek autorizacijskog koda
• OAuth2 implicitni tijek (engl. Implicit Flow).

Različiti tijekovi donose i različite razine sigurnosti autentikacijskog postupka. Na primjer, od trenutno podržana dva tijeka, tijek autorizacijskog koda ima veću razinu sigurnosti od implicitnog tijeka.

AAI@EduHr preporučuje korištenje tijeka autorizacijskog koda za autentikaciju korisnika neovisno o tome koji se tip klijenta koristi ili u kojem je programskom jeziku klijent implementiran.

Tijek autorizacijskog koda (engl. authorization code flow)

Tijek autorizacijskog koda je glavni i preporučeni način autenticiranja krajnjih korisnika koristeći protokol OIDC. Ovaj tijek u protokolu OIDC nadogradnja je postojećeg tijeka autorizacijskog koda u protokolu OAuth2. Glavne promjene koje u ovaj tijek donosi protokol OIDC u odnosu na OAuth2 su predefinirani OIDC opsezi i mogućnost izdavanja ID tokena.

Ukratko, tijek autorizacijskog koda obavlja se ovako:

1. klijent napravi autorizacijski HTTP zahtjev na autorizacijsku krajnju točku pomoću web-preglednika
2. krajnji korisnik se autenticira
3. autentikacijski poslužitelj preusmjeravanjem na registriranu lokaciju za preusmjeravanje (engl. redirect URI) šalje klijentu kratkotrajan (engl. short-lived) autorizacijski kod (kao GET parametar „code“)
4. klijent u pozadini (bez web-preglednika) napravi HTTP zahtjev na token krajnju točku koristeći dobiveni autorizacijski kod, a u HTTP odgovoru dobije pristupni token (engl. access token) te ID token ako je korišten opseg „openid“ (što je preporučeno).

Dakle, klijent dobije autorizacijski kod kojeg onda u pozadinskom kanalu (engl. back channel) direktno zamijeni za pristupni token i ID token. Ako se ne koristi opseg „openid“ (ako se ID token ne izdaje), korisničke podatke moguće je dohvatiti s krajnje točke za korisničke podatke (engl. userinfo endpoint). U tom slučaju zapravo se radi o OAuth2 tijeku autorizacijskog koda.

Slijedi primjer tijeka autorizacijskog koda za povjerljivog klijenta:

Video 3. Tijek autorizacijskog koda

U ovom tijeku bitno je shvatiti:

• autorizacijski kod prenosi se u prednjem kanalu, dakle u web-pregledniku, u URL-u samog zahtjeva prilikom preusmjeravanja
• ID token prenosi se u pozadinskom kanalu (nije izložen u URL-u)
• događa se autentikacija krajnjeg korisnika i vraćanje autorizacijskog koda u prednjem kanalu (pomoću web-preglednika)
• događa se autentikacija OIDC klijenta (Client ID i Secret) te razmjena ID tokena i pristupnog tokena u pozadinskom kanalu, dakle direktnom HTTP komunikacijom OIDC klijent <-> web server (ne koristi se web-preglednik).

Autorizacijski kod jest kratkotrajan token (engl. short-lived, u sustavu AAI@EduHr njegovo trajanje trenutno je 60 sekundi), čime se nastoji izbjeći njegova zlouporaba. No, čak i uz činjenicu da se autorizacijski kod prenosi u prednjem kanalu (u web-pregledniku u URL-u), ovaj tijek jamči dodatnu sigurnost zbog pozadinskog HTTP zahtjeva u kojem se autenticira sam OIDC klijent. U slučaju „proboja“ korisnikova web-preglednika, u smislu da treća strana dođe do autorizacijskog tokena, on se ne može iskoristiti bez tog zadnjeg koraka (bez da se autenticira i sam OIDC klijent).

Razlike u tijeku autorizacijskog koda za javne klijente

Tijek autorizacijskog koda je preporučeni način autenticiranja korisnika i za povjerljive i za javne klijente. No, da bi se autentikacija pomoću tijeka autorizacijskog koda mogla na siguran način obaviti i za javne klijente, postoje neke razlike:

• javni klijent ne koristi tajni ključ klijenta (engl. Client Secret)
• javni klijent koristi dodatne parametre prema standardu Proof Key for Code Exchange by OAuth Public Clients − PKCE („code_verifier“, „code_challenge“ i „code_challenge_method“)

Parametri „code_verifier“, „code_challenge“ i „code_challenge_method“ dio su dodatnog standarda Proof Key for Code Exchange by OAuth Public Clients − PKCE kojim se želi poboljšati sigurnost za javne klijente. Upravo zbog tog standarda javnim se klijentima omogućuje i preporučuje korištenje tijeka autorizacijskog koda za autentikaciju, umjesto da se koristi implicitni tijek. Vrijednosti koje mogu poprimiti parametri „code_verifier“, „code_challenge“ i „code_challenge_method“ detaljno su opisani u specifikaciji PKCE.

Iako na prvi pogled taj dodatni standard PKCE izgleda komplicirano, zapravo se radi o jednostavnom kreiranju nasumične vrijednosti iz koje se generira hash vrijednost. U  autorizacijskom zahtjevu koristi se hash vrijednost, a nakon toga u zahtjevu prema token krajnjoj točki koristi se prethodno kreirana nasumična vrijednost. Cilj je povezivanje autorizacijskog zahtjeva i zahtjeva prema token krajnjoj točki čime se osigurava da se odgovor s token krajnje točke vrati samo onom klijentu koji je prvotno i napravio autorizacijski zahtjev (u kojem se korisnik autenticirao). Dakle, radi se o obliku autentikacije klijenta.

OAuth2 implicitni tijek

Za razliku od tijeka autorizacijskog koda, u OAuth2 implicitnom tijeku izdaje se samo pristupni token (engl. access token). Dakle, ID token se ne izdaje, tj. korisnički podaci ne isporučuju se preko ID tokena. Za dohvat podataka o korisniku koristi se krajnja točka za korisničke podatke (engl. userinfo endpoint).

Ukratko, implicitni tijek obavlja se tako da:

1. klijent napravi autorizacijski HTTP zahtjev na autorizacijsku krajnju točku
2. krajnji korisnik se autenticira
3. klijent dobije natrag pristupni token kao fragment u URL-u (dio nakon znaka #)
4. klijent napravi HTTP zahtjev na krajnju točku za korisničke podatke pomoću pristupnog tokena.
    

Video 4. Implicitni tijek

Radi veće razine sigurnosti AAI@EduHr preporučuje korištenje tijeka autorizacijskog koda umjesto implicitnog tijeka. Primarni razlog je taj što je u OAuth2 implicitnom tijeku pristupni token (engl. access token) vidljiv u URL-u, a nema dodatnog koraka koji bi osigurao da se OIDC klijent autenticira na OP-u. Dakle, ako dođe do proboja u web-pregledniku krajnjeg korisnika i treća strana dođe do pristupnog tokena, ta treća strana može doći i do korisnikovih podataka.

Zaključak

OIDC (kao niti ostali autentikacijski protokoli) ne definira na koji način autenticirati korisnika, nego na koji način isporučiti korisničke podatke već autenticiranog korisnika. Da bi komunikacija između usluge (Relying Party - RP) i središnjih servisa (OpenID Provider − OP) mogla funkcionirati, potrebno je uspostaviti povjerenje razmjenom metapodataka, čime se definira:

• na koje URI-e će se slati autentikacijski zahtjevi i vraćati autentikacijski odgovori
• koji podaci će se o korisniku isporučivati RP-u (definirajući listu opsega, a time i tvrdnji).

Primaran način isporuke korisničkih podataka je da nakon autentikacije korisnika RP dobiva ID token iz kojeg čita korisničke podatke. Drugi način je dohvat korisničkih podataka s endpointa „userinfo“ (ako ne podržava čitanje ID tokena).

Detaljnije upute za developere dostupne su na ovoj poveznici.