Implementacija OAuth2: Obsežen vodnik za avtentikacijo tretje osebe

V današnji medsebojno povezani digitalni pokrajini je nemotena in varna avtentikacija uporabnikov najpomembnejša. OAuth2 se je pojavil kot industrijski standardni protokol za omogočanje aplikacijam tretjih oseb dostop do uporabniških virov na drugi storitvi, ne da bi razkrili svoje poverilnice. Ta obsežen vodnik se poglablja v zapletenosti implementacije OAuth2 in ponuja razvijalcem znanje in praktične smernice, potrebne za integracijo tega zmogljivega okvira za avtorizacijo v njihove aplikacije.

Kaj je OAuth2?

OAuth2 (Open Authorization) je okvir za avtorizacijo, ki omogoča aplikaciji tretje osebe, da pridobi omejen dostop do storitve HTTP v imenu uporabnika, bodisi z orkestriranjem odobritve s strani uporabnika ali pa z dovoljenjem aplikaciji tretje osebe, da pridobi dostop v svojem imenu. OAuth2 se osredotoča na preprostost razvijalca odjemalca, hkrati pa zagotavlja posebne tokove avtorizacije za spletne aplikacije, namizne aplikacije, mobilne telefone in naprave za dnevno sobo.

Pomislite na to kot na parkiranje z valetom. Ključe avtomobila (poverilnice) predate zaupanja vrednemu valetu (aplikacija tretje osebe), da lahko parkira vaš avto (dostopa do vaših virov), ne da bi mu morali neposredno dati dostop do vsega drugega v vašem avtomobilu. Obdržite nadzor in vedno lahko vzamete ključe nazaj (prekličete dostop).

Ključni koncepti v OAuth2

Razumevanje temeljnih konceptov OAuth2 je ključnega pomena za uspešno implementacijo:

• Lastnik vira: Entiteta, ki lahko odobri dostop do zaščitenega vira. Običajno je to končni uporabnik.
• Strežnik virov: Strežnik, ki gosti zaščitene vire, ki sprejema in se odziva na zaščitene zahteve za vire z uporabo žetonov za dostop.
• Odjemalska aplikacija: Aplikacija, ki zahteva dostop do zaščitenih virov v imenu lastnika vira. To je lahko spletna aplikacija, mobilna aplikacija ali namizna aplikacija.
• Strežnik za avtorizacijo: Strežnik, ki izda žetone za dostop odjemalski aplikaciji po uspešni avtentikaciji lastnika vira in pridobitvi njegove avtorizacije.
• Žeton za dostop: Poverilnica, ki predstavlja avtorizacijo, ki jo je lastnik vira podelil odjemalski aplikaciji. Odjemalska aplikacija jo uporablja za dostop do zaščitenih virov na strežniku virov. Žetoni za dostop imajo običajno omejeno življenjsko dobo.
• Žeton za osvežitev: Poverilnica, ki se uporablja za pridobitev novega žetona za dostop, ne da bi moral lastnik vira ponovno avtorizirati odjemalsko aplikacijo. Žetoni za osvežitev so običajno dolgotrajni in jih je treba varno shraniti.
• Obseg: Določa posebna dovoljenja, dodeljena odjemalski aplikaciji. Na primer, odjemalski aplikaciji se lahko odobri dostop samo za branje do uporabniškega profila, vendar ne možnost, da ga spremeni.

Vrste dodelitve OAuth2

OAuth2 določa več vrst dodelitve, od katerih je vsaka prilagojena posebnim primerom uporabe in varnostnim zahtevam. Izbira ustrezne vrste dodelitve je ključnega pomena za zagotavljanje varne in uporabniku prijazne izkušnje avtentikacije.

1. Dodelitev kode za avtorizacijo

Dodelitev kode za avtorizacijo je najpogosteje uporabljena in priporočena vrsta dodelitve za spletne aplikacije. Vključuje večstopenjski postopek, ki zagotavlja, da skrivnost odjemalca ni nikoli izpostavljena brskalniku lastnika vira. Zasnovana je za uporabo z zaupnimi odjemalci (odjemalci, ki lahko ohranijo zaupnost svoje skrivnosti odjemalca). Tukaj je poenostavljena razčlenitev:

1. Odjemalska aplikacija preusmeri lastnika vira na strežnik za avtorizacijo.
2. Lastnik vira se avtenticira s strežnikom za avtorizacijo in odobri dovoljenje odjemalski aplikaciji.
3. Strežnik za avtorizacijo preusmeri lastnika vira nazaj v odjemalsko aplikacijo s kodo za avtorizacijo.
4. Odjemalska aplikacija zamenja kodo za avtorizacijo za žeton za dostop in žeton za osvežitev.
5. Odjemalska aplikacija uporablja žeton za dostop za dostop do zaščitenih virov na strežniku virov.

Primer: Uporabnik želi povezati svoj račun Google Drive z aplikacijo za urejanje dokumentov tretje osebe. Aplikacija preusmeri uporabnika na Googlovo stran za avtentikacijo, kjer se prijavi in odobri aplikaciji dovoljenje za dostop do datotek v njegovem Google Drive. Google nato preusmeri uporabnika nazaj v aplikacijo s kodo za avtorizacijo, ki jo aplikacija zamenja za žeton za dostop in žeton za osvežitev.

2. Implicitna dodelitev

Implicitna dodelitev je poenostavljena različica dodelitve kode za avtorizacijo, zasnovana za odjemalske aplikacije, ki ne morejo varno shraniti skrivnosti odjemalca, kot so enostranske aplikacije (SPA), ki se izvajajo v spletnem brskalniku, ali izvorne mobilne aplikacije. V tej vrsti dodelitve se žeton za dostop neposredno vrne odjemalski aplikaciji, potem ko se lastnik vira avtenticira s strežnikom za avtorizacijo. Vendar pa se šteje za manj varno od dodelitve kode za avtorizacijo zaradi tveganja prestrezanja žetona za dostop.

Pomembno opozorilo: Implicitna dodelitev se zdaj v veliki meri šteje za zastarelo. Varnostne najboljše prakse priporočajo uporabo dodelitve kode za avtorizacijo s PKCE (Proof Key for Code Exchange) namesto nje, tudi za SPA in izvorne aplikacije.

3. Dodelitev poverilnic gesla lastnika vira

Dodelitev poverilnic gesla lastnika vira omogoča odjemalski aplikaciji, da pridobi žeton za dostop tako, da neposredno posreduje uporabniško ime in geslo lastnika vira strežniku za avtorizacijo. Ta vrsta dodelitve se sme uporabljati samo, kadar je odjemalska aplikacija zelo zaupanja vredna in ima neposreden odnos z lastnikom vira. Na splošno se odsvetuje zaradi varnostnih tveganj, povezanih z neposrednim deljenjem poverilnic z odjemalsko aplikacijo.

Primer: Mobilna aplikacija prve osebe, ki jo je razvila banka, lahko uporabi to vrsto dodelitve, da uporabnikom omogoči dostop do svojih računov. Vendar pa se morajo aplikacije tretjih oseb na splošno izogibati tej vrsti dodelitve.

4. Dodelitev poverilnic odjemalca

Dodelitev poverilnic odjemalca omogoča odjemalski aplikaciji, da pridobi žeton za dostop z uporabo svojih poverilnic (ID odjemalca in skrivnost odjemalca), namesto da deluje v imenu lastnika vira. Ta vrsta dodelitve se običajno uporablja za komunikacijo strežnik-strežnik ali kadar mora odjemalska aplikacija dostopati do virov, ki jih ima v lasti neposredno.

Primer: Aplikacija za spremljanje, ki mora dostopati do meritev strežnika od ponudnika oblaka, lahko uporabi to vrsto dodelitve.

5. Dodelitev žetona za osvežitev

Dodelitev žetona za osvežitev omogoča odjemalski aplikaciji, da pridobi nov žeton za dostop z uporabo žetona za osvežitev. To omogoča odjemalski aplikaciji, da ohrani dostop do zaščitenih virov, ne da bi moral lastnik vira ponovno avtorizirati aplikacijo. Žeton za osvežitev se zamenja za nov žeton za dostop in po možnosti nov žeton za osvežitev. Stari žeton za dostop je razveljavljen.

Implementacija OAuth2: Vodnik po korakih

Implementacija OAuth2 vključuje več ključnih korakov:

1. Registracija vaše odjemalske aplikacije

Prvi korak je registracija vaše odjemalske aplikacije pri strežniku za avtorizacijo. To običajno vključuje posredovanje informacij, kot so ime aplikacije, opis, URI-ji za preusmeritev (kam bo strežnik za avtorizacijo preusmeril lastnika vira po avtentikaciji) in želene vrste dodelitve. Strežnik za avtorizacijo bo nato izdal ID odjemalca in skrivnost odjemalca, ki bosta uporabljena za identifikacijo in avtentikacijo vaše aplikacije.

Primer: Ko registrirate svojo aplikacijo pri Googlovi storitvi OAuth2, boste morali navesti URI za preusmeritev, ki se mora ujemati z URI-jem, ki ga bo vaša aplikacija uporabila za prejemanje kode za avtorizacijo. Prav tako boste morali določiti obsege, ki jih zahteva vaša aplikacija, kot je dostop do Google Drive ali Gmail.

2. Začetek toka avtorizacije

Naslednji korak je začetek toka avtorizacije. To vključuje preusmeritev lastnika vira na končno točko za avtorizacijo strežnika za avtorizacijo. Končna točka za avtorizacijo bo običajno zahtevala naslednje parametre:

• client_id: ID odjemalca, ki ga je izdal strežnik za avtorizacijo.
• redirect_uri: URI, na katerega bo strežnik za avtorizacijo preusmeril lastnika vira po avtentikaciji.
• response_type: Vrsta odgovora, ki se pričakuje od strežnika za avtorizacijo (npr. code za dodelitev kode za avtorizacijo).
• scope: Želeni obsegi dostopa.
• state: Neobvezen parameter, ki se uporablja za preprečevanje napadov ponarejanja zahtev med mesti (CSRF).

Primer: URI za preusmeritev je lahko videti takole: https://example.com/oauth2/callback. Parameter state je naključno ustvarjeno niz, ki ga vaša aplikacija lahko uporabi za preverjanje, ali je odgovor strežnika za avtorizacijo legitimen.

3. Obravnava odgovora na avtorizacijo

Ko se lastnik vira avtenticira s strežnikom za avtorizacijo in odobri dovoljenje odjemalski aplikaciji, bo strežnik za avtorizacijo preusmeril lastnika vira nazaj na URI za preusmeritev odjemalske aplikacije s kodo za avtorizacijo (za dodelitev kode za avtorizacijo) ali žetonom za dostop (za implicitno dodelitev). Odjemalska aplikacija mora nato ustrezno obravnavati ta odgovor.

Primer: Če strežnik za avtorizacijo vrne kodo za avtorizacijo, jo mora odjemalska aplikacija zamenjati za žeton za dostop in žeton za osvežitev tako, da pošlje zahtevo POST na končno točko za žetone strežnika za avtorizacijo. Končna točka za žetone bo običajno zahtevala naslednje parametre:

• grant_type: Vrsta dodelitve (npr. authorization_code).
• code: Koda za avtorizacijo, prejeta od strežnika za avtorizacijo.
• redirect_uri: Ista URI za preusmeritev, uporabljena v zahtevi za avtorizacijo.
• client_id: ID odjemalca, ki ga je izdal strežnik za avtorizacijo.
• client_secret: Skrivnost odjemalca, ki jo je izdal strežnik za avtorizacijo (za zaupne odjemalce).

4. Dostop do zaščitenih virov

Ko odjemalska aplikacija pridobi žeton za dostop, ga lahko uporabi za dostop do zaščitenih virov na strežniku virov. Žeton za dostop je običajno vključen v glavi Authorization zahteve HTTP z uporabo sheme Bearer.

Primer: Za dostop do uporabniškega profila na platformi družbenih medijev lahko odjemalska aplikacija pošlje zahtevo, kot je ta:

  
  GET /api/v1/me HTTP/1.1
  Host: api.example.com
  Authorization: Bearer [access_token]
  

5. Obravnava osvežitve žetona

Žetoni za dostop imajo običajno omejeno življenjsko dobo. Ko žeton za dostop poteče, lahko odjemalska aplikacija uporabi žeton za osvežitev, da pridobi nov žeton za dostop, ne da bi moral lastnik vira ponovno avtorizirati aplikacijo. Za osvežitev žetona za dostop odjemalska aplikacija pošlje zahtevo POST na končno točko za žetone strežnika za avtorizacijo z naslednjimi parametri:

• grant_type: Vrsta dodelitve (npr. refresh_token).
• refresh_token: Žeton za osvežitev, prejet od strežnika za avtorizacijo.
• client_id: ID odjemalca, ki ga je izdal strežnik za avtorizacijo.
• client_secret: Skrivnost odjemalca, ki jo je izdal strežnik za avtorizacijo (za zaupne odjemalce).

Varnostni premisleki

OAuth2 je zmogljiv okvir za avtorizacijo, vendar je pomembno, da ga implementirate varno, da zaščitite uporabniške podatke in preprečite napade. Tukaj je nekaj ključnih varnostnih premislekov:

• Uporabite HTTPS: Vsa komunikacija med odjemalsko aplikacijo, strežnikom za avtorizacijo in strežnikom virov mora biti šifrirana z uporabo HTTPS, da se prepreči prisluškovanje.
• Preverite URI-je za preusmeritev: Previdno preverite URI-je za preusmeritev, da preprečite napade vbrizgavanja kode za avtorizacijo. Dovolite samo registrirane URI-je za preusmeritev in zagotovite, da so pravilno oblikovani.
• Zaščitite skrivnosti odjemalca: Ohranite skrivnosti odjemalca zaupne. Nikoli jih ne shranjujte v kodi na strani odjemalca ali jih ne izpostavljajte nepooblaščenim strankam.
• Implementirajte parameter stanja: Uporabite parameter state za preprečevanje napadov CSRF.
• Preverite žetone za dostop: Strežnik virov mora preveriti žetone za dostop, preden odobri dostop do zaščitenih virov. To običajno vključuje preverjanje podpisa žetona in časa poteka.
• Implementirajte obseg: Uporabite obsege za omejitev dovoljenj, dodeljenih odjemalski aplikaciji. Dodelite samo minimalna potrebna dovoljenja.
• Shranjevanje žetonov: Varno shranjujte žetone. Za izvorne aplikacije razmislite o uporabi varnih mehanizmov za shranjevanje operacijskega sistema. Za spletne aplikacije uporabite varne piškotke ali seje na strani strežnika.
• Upoštevajte PKCE (Proof Key for Code Exchange): Za aplikacije, ki ne morejo varno shraniti skrivnosti odjemalca (kot so SPA in izvorne aplikacije), uporabite PKCE za zmanjšanje tveganja prestrezanja kode za avtorizacijo.

OpenID Connect (OIDC)

OpenID Connect (OIDC) je avtentikacijska plast, zgrajena na vrhu OAuth2. Zagotavlja standardiziran način za odjemalske aplikacije, da preverijo identiteto lastnika vira na podlagi avtentikacije, ki jo izvede strežnik za avtorizacijo, pa tudi za pridobitev osnovnih informacij o profilu lastnika vira na interoperabilen način in način, podoben REST.

Medtem ko je OAuth2 predvsem okvir za avtorizacijo, OIDC dodaja komponento avtentikacije, zaradi česar je primeren za primere uporabe, kjer ne potrebujete samo avtorizacije dostopa do virov, temveč tudi preverjanje identitete uporabnika. OIDC uvaja koncept ID-žetona, ki je JSON Web Token (JWT), ki vsebuje trditve o identiteti uporabnika.

Pri implementaciji OIDC bo odgovor strežnika za avtorizacijo vključeval tako žeton za dostop (za dostop do zaščitenih virov) kot ID-žeton (za preverjanje identitete uporabnika).

Izbira ponudnika OAuth2

Lahko implementirate svoj strežnik za avtorizacijo OAuth2 ali uporabite ponudnika tretje osebe. Implementacija lastnega strežnika za avtorizacijo je lahko zapletena in dolgotrajna, vendar vam omogoča popoln nadzor nad postopkom avtentikacije. Uporaba ponudnika tretje osebe je pogosto enostavnejša in stroškovno učinkovitejša, vendar pomeni, da se pri avtentikaciji zanašate na tretjo osebo.

Nekateri priljubljeni ponudniki OAuth2 vključujejo:

• Google Identity Platform
• Facebook Login
• Microsoft Azure Active Directory
• Auth0
• Okta
• Ping Identity

Pri izbiri ponudnika OAuth2 upoštevajte dejavnike, kot so:

• Cena
• Funkcije
• Varnost
• Zanesljivost
• Enostavnost integracije
• Zahteve glede skladnosti (npr. GDPR, CCPA)
• Podpora za razvijalce

OAuth2 v različnih okoljih

OAuth2 se uporablja v številnih različnih okoljih, od spletnih aplikacij in mobilnih aplikacij do namiznih aplikacij in naprav IoT. Posebne podrobnosti implementacije se lahko razlikujejo glede na okolje, vendar temeljni koncepti in načela ostajajo enaki.

Spletne aplikacije

V spletnih aplikacijah se OAuth2 običajno implementira z uporabo dodelitve kode za avtorizacijo s kodo na strani strežnika, ki obravnava izmenjavo in shranjevanje žetonov. Za enostranske aplikacije (SPA) je priporočen pristop dodelitev kode za avtorizacijo s PKCE.

Mobilne aplikacije

V mobilnih aplikacijah se OAuth2 običajno implementira z uporabo dodelitve kode za avtorizacijo s PKCE ali izvornim SDK, ki ga zagotavlja ponudnik OAuth2. Pomembno je, da žetone za dostop varno shranite z uporabo varnih mehanizmov za shranjevanje operacijskega sistema.

Namizne aplikacije

V namiznih aplikacijah je mogoče OAuth2 implementirati z uporabo dodelitve kode za avtorizacijo z vdelanim brskalnikom ali sistemskim brskalnikom. Podobno kot pri mobilnih aplikacijah je pomembno, da žetone za dostop varno shranite.

Naprave IoT

V napravah IoT je implementacija OAuth2 lahko bolj zahtevna zaradi omejenih virov in varnostnih omejitev teh naprav. Glede na posebne zahteve se lahko uporabi dodelitev poverilnic odjemalca ali poenostavljena različica dodelitve kode za avtorizacijo.

Odpravljanje pogostih težav z OAuth2

Implementacija OAuth2 je včasih lahko zahtevna. Tukaj je nekaj pogostih težav in kako jih odpraviti:

• Neveljaven URI za preusmeritev: Zagotovite, da se URI za preusmeritev, registriran pri strežniku za avtorizacijo, ujema z URI-jem, ki se uporablja v zahtevi za avtorizacijo.
• Neveljaven ID ali skrivnost odjemalca: Ponovno preverite, ali sta ID odjemalca in skrivnost odjemalca pravilna.
• Nepooblaščen obseg: Zagotovite, da strežnik za avtorizacijo podpira zahtevane obsege in da je odjemalski aplikaciji odobreno dovoljenje za dostop do njih.
• Žeton za dostop je potekel: Uporabite žeton za osvežitev, da pridobite nov žeton za dostop.
• Preverjanje žetona ni uspelo: Zagotovite, da je strežnik virov pravilno konfiguriran za preverjanje žetonov za dostop.
• Napake CORS: Če naletite na napake deljenja virov med mesti (CORS), zagotovite, da sta strežnik za avtorizacijo in strežnik virov pravilno konfigurirana, da dovolita zahteve iz izvora vaše odjemalske aplikacije.

Zaključek

OAuth2 je zmogljiv in vsestranski okvir za avtorizacijo, ki omogoča varno in nemoteno avtentikacijo uporabnikov za široko paleto aplikacij. Z razumevanjem temeljnih konceptov, vrst dodelitve in varnostnih premislekov lahko razvijalci učinkovito implementirajo OAuth2 za zaščito uporabniških podatkov in zagotavljanje odlične uporabniške izkušnje.

Ta vodnik je ponudil obsežen pregled implementacije OAuth2. Ne pozabite se posvetovati z uradnimi specifikacijami OAuth2 in dokumentacijo izbranega ponudnika OAuth2 za podrobnejše informacije in smernice. Vedno dajte prednost varnostnim najboljšim praksam in bodite na tekočem z najnovejšimi priporočili, da zagotovite celovitost in zaupnost uporabniških podatkov.