OAuth2 rakendamine: põhjalik juhend kolmanda osapoole autentimiseks

Tänapäeva omavahel ühendatud digitaalses maastikus on sujuv ja turvaline kasutaja autentimine ülimalt tähtis. OAuth2 on tõusnud tööstusstandardi protokolliks, mis võimaldab kolmandate osapoolte rakendustel pääseda kasutaja ressurssidele teises teenuses, ilma nende mandaate paljastamata. See põhjalik juhend süveneb OAuth2 rakendamise keerukustesse, pakkudes arendajatele teadmisi ja praktilisi juhiseid selle võimsa autoriseerimisraamistiku integreerimiseks oma rakendustesse.

Mis on OAuth2?

OAuth2 (Open Authorization) on autoriseerimisraamistik, mis võimaldab kolmanda osapoole rakendusel saada piiratud juurdepääsu HTTP-teenusele kasutaja nimel, korraldades kas kasutaja heakskiidu või võimaldades kolmanda osapoole rakendusel saada juurdepääs oma nimel. OAuth2 keskendub kliendi arendaja lihtsusele, pakkudes samal ajal spetsiifilisi autoriseerimisvooge veebirakenduste, töölauarakenduste, mobiiltelefonide ja elutoa seadmete jaoks.

Mõelge sellele nagu autoparkimisele. Annate oma autovõtmed (mandaadid) usaldusväärsele parklale (kolmanda osapoole rakendus), et nad saaksid teie auto parkida (juurdepääs teie ressurssidele), ilma et peaksite neile otse juurdepääsu andma kõigele muule autos. Sa säilitad kontrolli ja saad alati oma võtmed kätte (juurdepääsu tühistada).

OAuth2 põhikonseptsioonid

OAuth2 põhikontseptsioonide mõistmine on eduka rakendamise jaoks ülioluline:

• Ressursi omanik: üksus, mis on võimeline andma juurdepääsu kaitstud ressursile. Tavaliselt on see lõppkasutaja.
• Ressursiserver: server, mis majutab kaitstud ressursse, mis aktsepteerib ja vastab kaitstud ressursitaotlustele, kasutades juurdepääsumärke.
• Kliendirakendus: rakendus, mis taotleb juurdepääsu kaitstud ressurssidele ressursi omaniku nimel. See võib olla veebirakendus, mobiilirakendus või töölauarakendus.
• Autoriseerimisserver: server, mis väljastab juurdepääsumärke kliendirakendusele pärast ressursi omaniku edukat autentimist ja tema autoriseeringu saamist.
• Juurdepääsumärk: mandaat, mis esindab ressursi omaniku poolt kliendirakendusele antud autoriseeringut. Kliendirakendus kasutab seda kaitstud ressurssidele ressursiserveris juurdepääsuks. Juurdepääsumärgid on tavaliselt piiratud elueaga.
• Värskendusmärk: mandaat, mida kasutatakse uue juurdepääsumärgi saamiseks, ilma et oleks vaja ressursi omanikult kliendirakendust uuesti autoriseerida. Värskendusmärgid on tavaliselt pikaealised ja neid tuleks turvaliselt hoida.
• Ulatus: määratleb kliendirakendusele antud konkreetsed õigused. Näiteks võidakse kliendirakendusele anda ainult lugemisõigus kasutaja profiilile, kuid mitte võimalus seda muuta.

OAuth2 lubatüübid

OAuth2 määratleb mitu lubatüüpi, millest igaüks on kohandatud konkreetsetele kasutusjuhtudele ja turvanõuetele. Õige lubatüübi valimine on turvalise ja kasutajasõbraliku autentimiskogemuse tagamiseks ülioluline.

1. Autoriseerimiskoodi luba

Autoriseerimiskoodi luba on kõige sagedamini kasutatav ja soovitatav lubatüüp veebirakenduste jaoks. See hõlmab mitmeastmelist protsessi, mis tagab, et kliendi saladust ei avaldata kunagi ressursi omaniku brauserile. See on mõeldud kasutamiseks konfidentsiaalsete klientidega (kliendid, kes suudavad säilitada oma kliendi saladuse konfidentsiaalsust). Siin on lihtsustatud ülevaade:

1. Kliendirakendus suunab ressursi omaniku autoriseerimisserverisse.
2. Ressursi omanik autentib end autoriseerimisserveris ja annab kliendirakendusele loa.
3. Autoriseerimisserver suunab ressursi omaniku tagasi kliendirakendusse koos autoriseerimiskoodiga.
4. Kliendirakendus vahetab autoriseerimiskoodi juurdepääsumärgi ja värskendusmärgi vastu.
5. Kliendirakendus kasutab juurdepääsumärki, et pääseda kaitstud ressurssidele ressursiserveris.

Näide: Kasutaja soovib ühendada oma Google Drive'i konto kolmanda osapoole dokumenditöötlusrakendusega. Rakendus suunab kasutaja Google'i autentimislehele, kus ta logib sisse ja annab rakendusele loa oma Google Drive'i failidele juurde pääseda. Seejärel suunab Google kasutaja tagasi rakendusse koos autoriseerimiskoodiga, mille rakendus vahetab juurdepääsumärgi ja värskendusmärgi vastu.

2. Kaudne luba

Kaudne luba on autoriseerimiskoodi loa lihtsustatud versioon, mis on mõeldud kliendirakenduste jaoks, mis ei saa turvaliselt hoida kliendi saladust, näiteks ühe lehe rakendused (SPA) veebibrauseris või põhirakendused. Selles lubatüübis tagastatakse juurdepääsumärk otse kliendirakendusele pärast seda, kui ressursi omanik on autoriseerimisserveriga autentinud. Kuid seda peetakse vähem turvaliseks kui autoriseerimiskoodi luba, kuna on oht, et juurdepääsumärki peetakse kinni.

Oluline märkus: Kaudset luba peetakse nüüd suuresti aegunuks. Turvalisuse parimad tavad soovitavad kasutada autoriseerimiskoodi luba koos PKCE-ga (Proof Key for Code Exchange), isegi SPA-de ja põhirakenduste puhul.

3. Ressursi omaniku parooliga mandaatide luba

Ressursi omaniku parooliga mandaatide luba võimaldab kliendirakendusel saada juurdepääsumärgi, esitades otse ressursi omaniku kasutajanime ja parooli autoriseerimisserverile. Seda lubatüüpi tuleks kasutada ainult siis, kui kliendirakendust usaldatakse väga ja sellel on otsene suhe ressursi omanikuga. Üldiselt ei soovitata seda, kuna on oht jagada mandaate otse kliendirakendusega.

Näide: Pank arendatud esimese osapoole mobiilirakendus võib kasutada seda lubatüüpi, et võimaldada kasutajatel oma kontodele juurde pääseda. Kuid kolmanda osapoole rakendused peaksid seda lubatüüpi üldiselt vältima.

4. Kliendimandaatide luba

Kliendimandaatide luba võimaldab kliendirakendusel saada juurdepääsumärgi, kasutades oma mandaate (kliendi ID ja kliendi saladus) selle asemel, et tegutseda ressursi omaniku nimel. Seda lubatüüpi kasutatakse tavaliselt serveritevaheliseks suhtluseks või siis, kui kliendirakendus peab pääsema juurde ressurssidele, mis kuuluvad talle otse.

Näide: jälgimisrakendus, mis peab pääsema pilvepakkuja serveri mõõdikutele, võib kasutada seda lubatüüpi.

5. Värskendusmärgi luba

Värskendusmärgi luba võimaldab kliendirakendusel saada uue juurdepääsumärgi, kasutades värskendusmärki. See võimaldab kliendirakendusel säilitada juurdepääsu kaitstud ressurssidele, ilma et oleks vaja ressursi omanikku rakendust uuesti autoriseerida. Värskendusmärk vahetatakse uue juurdepääsumärgi ja valikuliselt uue värskendusmärgi vastu. Vana juurdepääsumärk kehtetuks tunnistatakse.

OAuth2 rakendamine: samm-sammuline juhend

OAuth2 rakendamine hõlmab mitut põhisammu:

1. Kliendirakenduse registreerimine

Esimene samm on kliendirakenduse registreerimine autoriseerimisserveriga. See hõlmab tavaliselt teabe esitamist, nagu rakenduse nimi, kirjeldus, ümbersuunamise URI-d (kus autoriseerimisserver suunab ressursi omaniku pärast autentimist ümber) ja soovitud lubatüübid. Seejärel annab autoriseerimisserver välja kliendi ID ja kliendi saladuse, mida kasutatakse teie rakenduse tuvastamiseks ja autentimiseks.

Näide: Rakenduse registreerimisel Google'i OAuth2 teenusega peate esitama ümbersuunamise URI, mis peab vastama URI-le, mida teie rakendus kasutab autoriseerimiskoodi vastuvõtmiseks. Samuti peate määrama rakenduse nõutud ulatuse, näiteks juurdepääsu Google Drive'ile või Gmailile.

2. Autoriseerimisvoo algatamine

Järgmine samm on autoriseerimisvoo algatamine. See hõlmab ressursi omaniku suunamist autoriseerimisserveri autoriseerimispunkti. Autoriseerimispunkt nõuab tavaliselt järgmisi parameetreid:

• client_id: autoriseerimisserveri väljastatud kliendi ID.
• redirect_uri: URI, millele autoriseerimisserver suunab ressursi omaniku pärast autentimist ümber.
• response_type: autoriseerimisserverilt oodatav vastuse tüüp (nt code autoriseerimiskoodi loa jaoks).
• scope: soovitud juurdepääsuulatus.
• state: valikuline parameeter, mida kasutatakse saitidevaheliste päringute võltsimise (CSRF) rünnakute vältimiseks.

Näide: Ümbersuunamise URI võib välja näha selline: https://example.com/oauth2/callback. Parameeter state on juhuslikult genereeritud string, mida teie rakendus saab kasutada, et kontrollida, et vastus autoriseerimisserverist on seaduslik.

3. Autoriseerimisvastuse käsitlemine

Pärast seda, kui ressursi omanik on autoriseerimisserveriga autentinud ja kliendirakendusele loa andnud, suunab autoriseerimisserver ressursi omaniku tagasi kliendirakenduse ümbersuunamise URI-le kas autoriseerimiskoodiga (autoriseerimiskoodi loa jaoks) või juurdepääsumärgiga (kaudse loa jaoks). Seejärel peab kliendirakendus seda vastust asjakohaselt käsitlema.

Näide: Kui autoriseerimisserver tagastab autoriseerimiskoodi, peab kliendirakendus selle vahetama juurdepääsumärgi ja värskendusmärgi vastu, tehes POST-päringu autoriseerimisserveri märgipunkti. Märgipunkt nõuab tavaliselt järgmisi parameetreid:

• grant_type: lubatüüp (nt authorization_code).
• code: autoriseerimiskood, mis saadi autoriseerimisserverist.
• redirect_uri: sama ümbersuunamise URI, mida kasutati autoriseerimistaotluses.
• client_id: autoriseerimisserveri väljastatud kliendi ID.
• client_secret: autoriseerimisserveri väljastatud kliendi saladus (konfidentsiaalsete klientide jaoks).

4. Kaitstud ressurssidele juurdepääs

Kui kliendirakendus on saanud juurdepääsumärgi, saab ta seda kasutada kaitstud ressurssidele ressursiserveris juurdepääsuks. Juurdepääsumärk sisaldub tavaliselt HTTP-päringu päises Authorization, kasutades skeemi Bearer.

Näide: Sotsiaalmeediaplatvormi kasutaja profiilile juurdepääsuks võib kliendirakendus teha taotluse selline:

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

5. Märgi värskendamise käsitlemine

Juurdepääsumärgid on tavaliselt piiratud elueaga. Kui juurdepääsumärk aegub, saab kliendirakendus värskendusmärgi abil hankida uue juurdepääsumärgi, ilma et oleks vaja ressursi omanikku rakendust uuesti autoriseerida. Juurdepääsumärgi värskendamiseks teeb kliendirakendus autoriseerimisserveri märgipunkti POST-päringu järgmiste parameetritega:

• grant_type: lubatüüp (nt refresh_token).
• refresh_token: autoriseerimisserverist saadud värskendusmärk.
• client_id: autoriseerimisserveri väljastatud kliendi ID.
• client_secret: autoriseerimisserveri väljastatud kliendi saladus (konfidentsiaalsete klientide jaoks).

Turvakaalutlused

OAuth2 on võimas autoriseerimisraamistik, kuid on oluline seda rakendada turvaliselt, et kaitsta kasutajaandmeid ja vältida rünnakuid. Siin on mõned peamised turvakaalutlused:

• Kasuta HTTPS-i: Kogu suhtlus kliendirakenduse, autoriseerimisserveri ja ressursiserveri vahel peaks olema krüpteeritud, kasutades HTTPS-i, et vältida pealtkuulamist.
• Valideeri ümbersuunamise URI-d: Valideeri ümbersuunamise URI-sid hoolikalt, et vältida autoriseerimiskoodi sissepritse rünnakuid. Luba ainult registreeritud ümbersuunamise URI-sid ja veendu, et need on õigesti vormindatud.
• Kaitse kliendi salajasi andmeid: Hoia kliendi saladused konfidentsiaalsena. Ära kunagi säilita neid kliendipoolses koodis või avalda neid volitamata isikutele.
• Rakenda oleku parameeter: Kasuta parameetrit state CSRF-rünnakute vältimiseks.
• Valideeri juurdepääsumärgid: Ressursiserver peab juurdepääsu lubamisele kaitstud ressurssidele juurdepääsu lubamisel juurdepääsumärke valideerima. See hõlmab tavaliselt märgi allkirja ja aegumise aja kontrollimist.
• Rakenda ulatus: Kasuta ulatust, et piirata kliendirakendusele antud õigusi. Anna ainult minimaalsed vajalikud õigused.
• Märgi salvestamine: Salvesta märgid turvaliselt. Põhirakenduste puhul kaaluge operatsioonisüsteemi turvaliste salvestusmehhanismide kasutamist. Veebirakenduste puhul kasuta turvalisi küpsiseid või serveripoolseid seansse.
• Kaalu PKCE-d (Proof Key for Code Exchange): Rakenduste puhul, mis ei saa turvaliselt salvestada kliendi saladust (nagu SPA-d ja põhirakendused), kasuta PKCE-d autoriseerimiskoodi kinnipidamise ohu leevendamiseks.

OpenID Connect (OIDC)

OpenID Connect (OIDC) on autentimiskih, mis on ehitatud OAuth2 peale. See pakub standardiseeritud viisi, kuidas kliendirakendused saavad kontrollida ressursi omaniku identiteeti autoriseerimisserveri tehtud autentimise põhjal, samuti saada põhiteavet ressursi omaniku profiili kohta koostalitlusvõimelisel ja REST-sarnasel viisil.

Kuigi OAuth2 on peamiselt autoriseerimisraamistik, lisab OIDC autentimiskomponendi, muutes selle sobivaks kasutusjuhtudeks, kus peate mitte ainult autoriseerima juurdepääsu ressurssidele, vaid ka kontrollima kasutaja identiteeti. OIDC tutvustab ID-märgi mõistet, mis on JSON Web Token (JWT), mis sisaldab kasutaja identiteedi kohta väiteid.

OIDC rakendamisel sisaldab vastus autoriseerimisserverist nii juurdepääsumärki (kaitstud ressurssidele juurdepääsuks) kui ka ID-märki (kasutaja identiteedi kontrollimiseks).

OAuth2 pakkuja valimine

Saate kas rakendada oma OAuth2 autoriseerimisserveri või kasutada kolmanda osapoole pakkujat. Oma autoriseerimisserveri rakendamine võib olla keeruline ja aeganõudev, kuid see annab teile täieliku kontrolli autentimisprotsessi üle. Kolmanda osapoole pakkuja kasutamine on sageli lihtsam ja kuluefektiivsem, kuid see tähendab, et tuginete autentimisel kolmandale osapoolele.

Mõned populaarsed OAuth2 pakkujad on:

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

OAuth2 pakkuja valimisel arvesta selliste teguritega nagu:

• Hind
• Funktsioonid
• Turvalisus
• Usaldusväärsus
• Lihtne integreerimine
• Vastavusnõuded (nt GDPR, CCPA)
• Arendajatoetus

OAuth2 erinevates keskkondades

OAuth2 kasutatakse paljudes keskkondades, alates veebirakendustest ja mobiilirakendustest kuni töölauarakenduste ja asjade interneti seadmeteni. Konkreetsed rakenduse üksikasjad võivad olenevalt keskkonnast erineda, kuid põhikontseptsioonid ja -põhimõtted jäävad samaks.

Veebirakendused

Veebirakendustes rakendatakse OAuth2 tavaliselt autoriseerimiskoodi abil serveripoolse koodiga, mis tegeleb märgi vahetamise ja salvestamisega. Ühe lehe rakenduste (SPA-de) puhul on soovitatav lähenemisviis autoriseerimiskoodi kasutamine koos PKCE-ga.

Mobiilirakendused

Mobiilirakendustes rakendatakse OAuth2 tavaliselt autoriseerimiskoodi abil koos PKCE-ga või OAuth2 pakkuja pakutud põhi SDK-ga. Oluline on salvestada juurdepääsumärgid turvaliselt, kasutades operatsioonisüsteemi turvalisi salvestusmehhanisme.

Töölauarakendused

Töölauarakendustes saab OAuth2 rakendada autoriseerimiskoodi abil koos sisseehitatud brauseriga või süsteemibrauseriga. Sarnaselt mobiilirakendustega on oluline juurdepääsumärke turvaliselt säilitada.

Asjade interneti seadmed

Asjade interneti seadmetes võib OAuth2 rakendamine olla keerulisem nende seadmete piiratud ressursside ja turvapiirangute tõttu. Võib kasutada kliendimandaatide luba või autoriseerimiskoodi loa lihtsustatud versiooni, olenevalt konkreetsetest nõuetest.

Probleemide lahendamine OAuth2 levinud probleemide korral

OAuth2 rakendamine võib mõnikord olla keeruline. Siin on mõned levinud probleemid ja nende lahendamine:

• Kehtetu ümbersuunamise URI: Veenduge, et autoriseerimisserveriga registreeritud ümbersuunamise URI vastab autoriseerimistaotluses kasutatud URI-le.
• Kehtetu kliendi ID või saladus: Kontrollige veel kord, et kliendi ID ja kliendi saladus on õiged.
• Volitamata ulatus: Veenduge, et autoriseerimisserver toetab nõutud ulatust ja et kliendirakendusele on antud luba neile juurdepääsuks.
• Juurdepääsumärgi aegumine: Kasutage uue juurdepääsumärgi saamiseks värskendusmärki.
• Märgi valideerimine nurjus: Veenduge, et ressursiserver on õigesti konfigureeritud juurdepääsumärke valideerima.
• CORS-i vead: Kui teil esinevad saitidevahelise ressursi jagamise (CORS) vead, veenduge, et autoriseerimisserver ja ressursiserver on õigesti konfigureeritud, et lubada päringuid teie kliendirakenduse algusest.

Järeldus

OAuth2 on võimas ja mitmekülgne autoriseerimisraamistik, mis võimaldab turvalist ja sujuvat kasutaja autentimist paljude rakenduste jaoks. Mõistes põhikontseptsioone, lubatüüpe ja turvakaalutlusi, saavad arendajad OAuth2 tõhusalt rakendada, et kaitsta kasutajaandmeid ja pakkuda suurepärast kasutuskogemust.

See juhend on andnud OAuth2 rakendamisest põhjaliku ülevaate. Täpsema teabe ja juhiste saamiseks pidage meeles, et tutvuge ametlike OAuth2 spetsifikatsioonidega ja valitud OAuth2 pakkuja dokumentatsiooniga. Seadke alati esikohale turvalisuse parimad tavad ja püsige kursis viimaste soovitustega, et tagada kasutajaandmete terviklikkus ja konfidentsiaalsus.