ProHoster > Blog > Administrazioa > Identitate Zerbitzaria 4. Oinarrizko kontzeptuak. OpenID Connect, OAuth 2.0 eta JWT

Identitate Zerbitzaria 4. Oinarrizko kontzeptuak. OpenID Connect, OAuth 2.0 eta JWT

Post honekin IdentityServer4-ri eskainitako artikuluen haria ireki nahi dut. Has gaitezen oinarrizko kontzeptuetatik.

Momentu honetan itxaropentsuena den autentifikazio-protokoloa da OpenID Connect, eta baimen-protokoloa (sarbidea ematen duena) da OAuth 2.0. Identitate Zerbitzaria 4 bi protokolo hauek ezartzen ditu. Ebazteko optimizatuta dago arazo tipikoak segurtasuna.

OpenID Connect autentifikazio-protokoloa eta estandarra da, ez du baliabideetarako sarbidea ematen (Web APIa), baina geroztik baimen-protokoloaren gainean diseinatuta dago OAuth 2.0, erabiltzaile-profilaren parametroak lortzeko aukera ematen du baliabiderako sarbidea izango bazenu bezala Erabiltzailearen informazioa.

J.W.T. (JSON Web Token) erabiltzaileen datuak JSON formatuan enkriptatutako forma batean transmititzeko modu bat definitzen duen web estandarra da.

OAuth 2.0 (RFC 6749) baimen-protokoloa eta estandarra da. Aplikazioei babestutako baliabideetara sartzeko aukera ematen die, hala nola, Web APIetara.

Ikus ditzagun babestutako baliabide batera sartzeko diagrama eta uler ditzagun urrats nagusiak eta onartutako terminologia:

Identitate Zerbitzaria 4. Oinarrizko kontzeptuak. OpenID Connect, OAuth 2.0 eta JWT

  1. Bezeroak erabiltzaileari baimena eskatzen dio bere izenean autentifikatzeko. bezero Baliabideen jabearen izenean babestutako baliabideak atzitzen dituen bezero-aplikazioa da. baliabidea - Hauek dira gure babestutako zerbitzu guztiak Web APIa.

  2. Erabiltzaileak bezeroaren aplikazioari bere izenean autentifikatzeko aukera ematen dio, adibidez, saio-hasiera eta pasahitza sartuz. Saio-hasiera eta pasahitza bezeroaren aplikaziorako baimena izango da. Erabiltzailea (baliabideen jabea) — Babestutako baliabideetarako sarbidea eman dezakeen programa edo pertsona bat, adibidez, saioa hasteko (erabiltzaile-izena) eta pasahitza (pasahitza) sartuz;

  3. Bezeroaren aplikazioak sarbide-token bat eskatzen dio IdentityServer4 zeure buruari buruzko informazioa emanez (client_id, client_secret), erabiltzailearen baimena ematea (username, password) eta eskainiz grant_type и scope. Ondoren, baimen-zerbitzariak bezeroaren benetakotasuna eta baliabideen jabearen xehetasunak (saioa eta pasahitza) egiaztatzen ditu.

    OAuth 2.0 protokoloak erabiltzailea ez ezik, baliabideak atzitzen dituen bezero aplikazioa ere autentifikatzen du. Horretarako, protokoloak parametro hauek eskaintzen ditu bezero_id и bezero_sekretua.
    bezero_id erabiltzen den bezero-aplikazioaren identifikatzailea da IdentityServer4 bezeroari buruzko informazioa bilatzeko.
    bezero_sekretua Bezero-aplikazio baten pasahitz baten antzekoa da eta bezero-aplikazioa autentifikatzeko erabiltzen da IdentityServer4. Bezeroaren sekretua aplikazioak eta APIak soilik ezagutu behar dute. Aurrekoan oinarrituta, hori ondorioztatzen dugu IdentityServer4-k bere bezeroei buruz jakin behar du.

  4. Aplikazioa autentifikatuta badago eta baimen-baimena baliozkoa bada, IdentiryServer4 sortzen du access-токен (sarbide-tokena) aplikaziorako eta aukerako freskatze-gako bat (refresh-токен). Baimen-prozesua amaitu da. Eskaera baliogabea edo baimenik gabekoa bada, baimen-zerbitzariak kode bat itzultzen du errore-mezu egoki batekin.

  5. Bezeroaren aplikazioak datuetarako Web API seguru batera atzitzen du, baimena lortzeko sarbide-token bat emanez. Baliabide zerbitzariaren erantzun-kodea bada 401, 403 edo 498, orduan autentifikaziorako erabilitako sarbide-tokena baliogabea edo iraungi da.

  6. Tokena baliozkoa bada, Web API aplikazioari datuak ematen dizkio.

Token motak

urtean erregistratuta IdentityServer4 bezeroek eskatzeko baimena dute IdentityServer4 identity-token, access-token eta refresh-token.

  • identitate-token (identifikazio-token) — autentifikazio-prozesuaren emaitza. Erabiltzailearen IDa eta erabiltzailea nola eta noiz autentifikatzen den buruzko informazioa ditu. Zure datuekin zabaldu dezakezu.
  • sarbide-tokena — Babestutako API batera transmititzen da eta honek bere datuak baimentzeko (sartzea baimentzeko) erabiltzen du.
  • refresh-token (freskatzeko token) baimen-zerbitzariak sarbide-token eskaera bati erantzunez itzul dezakeen aukerako parametro bat da.

Sar ditzagun beste bi kontzeptu:

Autentifikazio-zerbitzariaren URLa — sarbide-gakoa lortzeko amaiera-puntua. Sarbide-gakoak hornitzeko eta berritzeko eskaera guztiak URL honetara zuzenduko ditugu.

Baliabidearen URLa — Bertara atzitzeko harremanetan jarri behar den babestutako baliabidearen URLa, baimenaren goiburuko sarbide-gakoa pasatuz.

Sarbide-gako eskaera

Sarbide-gakoa eskatzeko, bezeroak egiten du POST amaiera punturako eskaera IdentityServer4 hurrengo goiburuarekin

'Content-Type': 'application/x-www-form-urlencoded',
'Accept': 'application/json',
'Expect': '100-continue'

eta parametro hauek pasatuz:

'grant_type' : 'password',
'username' : login,
'password' : password,
'scope' : 'scope',
'client_id' : 'client_id',
'client_secret' : '{client_secret}'

username, password, client_id и client_secret goian eztabaidatu ziren. Ikus ditzagun gainerako parametroak:

beka_mota — Beka mota edo baimen mota. Baimen-baimen mota aplikazioak erabiltzen duen baimen-eskaera metodoaren araberakoa da, baita APIak onartzen dituen baimen motak ere. Gure kasuan garrantzia izango du password, zehaztapenaren araberakoa OAuth 2.0 Baliabidearen jabearen sarbide-datuei dagokie (saio-hasiera eta pasahitz bidezko baimena).

protokoloa OAuth 2.0 eskatzen dituen diru-laguntza mota hauek definitzen ditu erabiltzaileekin derrigorrezko interakzioa:

  • baimen-kodea. Baimen-baimen mota ohikoenetako bat da, zeren zerbitzariaren aldeko aplikazioetarako oso egokia, non aplikazioaren iturburu-kodea eta bezeroaren sekretua kanpokoentzat eskuragarri ez dauden;
  • inplizitua. Baimen inplizitua baimen-mota mugikor eta web aplikazioek erabiltzen dute, non bezeroaren sekretuaren konfidentzialtasuna bermatu ezin den;

Eta diru-laguntza mota hori erabiltzailearen interakziorik gabe exekutatu daiteke:

  • baliabideen jabearen xehetasunak. Baimen mota hau bezeroaren aplikazioan erabiltzaileak fidagarria bada eta erabiltzailea saio-hasiera eta pasahitza sartzen eroso badago soilik erabili behar da. Baimen mota hau beste aukerarik erabilgarri ez dagoenean bakarrik erabili behar da. Baimen mota hau komenigarria da sistemaren barruan erabiltzaileen kredentzialak erabili dituzten bezero korporatiboentzat eta aldatu nahi dutenentzat OAuth 2.0.
  • bezeroaren kredentzialak. Aplikazioa APIra sartzen denean erabiltzen da. Hau erabilgarria izan daiteke, adibidez, aplikazio batek bere zerbitzua erregistratzeko informazioa eguneratu nahi duenean edo birbideratu nahi duen URIa, edo aplikazioaren zerbitzu-kontuan gordetako beste informaziora sartu nahi duenean zerbitzu-APIaren bidez.

esparrua - Aukerako parametroa da. Eremua zehazten du. Zerbitzariak itzultzen duen sarbide-tokenak esparru horretan sartzen diren zerbitzuetarako sarbidea emango du soilik. Horiek. hainbat zerbitzu konbinatu ditzakegu esparru bakarrean eta bezeroak esparru honetarako sarbide-gako bat jasotzen badu, zerbitzu guztietarako sarbidea izango du. Eremua baimen-eskubideak mugatzeko ere erabil daiteke (adibidez, irakurtzeko edo idazteko sarbidea)

Iturria: www.habr.com

Gehitu iruzkin berria