Märge. tõlge: See suurepärane Okta artikkel selgitab lihtsalt ja selgelt, kuidas OAuth ja OIDC (OpenID Connect) töötavad. Need teadmised on kasulikud populaarsete veebirakenduste arendajatele, süsteemiadministraatoritele ja isegi "tavakasutajatele", kes tõenäoliselt vahetavad ka konfidentsiaalseid andmeid teiste teenustega.
Interneti kiviajal oli teabe jagamine teenuste vahel lihtne. Andsite lihtsalt oma sisselogimise ja parooli ühest teenusest teise, nii et ta sisenes teie kontole ja sai kogu vajaliku teabe.
"Anna mulle oma pangakonto." «Lubame, et salasõna ja rahaga saab kõik korda. See on aus, aus!" *hee hee*
Õudus! Keegi ei tohiks kunagi nõuda, et kasutaja jagaks kasutajanime ja parooli, volikirjad, teise teenusega. Ei ole mingit garantiid, et selle teenuse taga olev organisatsioon hoiab andmeid turvaliselt ega kogu vajalikust rohkem isiklikku teavet. See võib tunduda hullumeelne, kuid mõned rakendused kasutavad seda praktikat endiselt!
Tänapäeval on üks standard, mis võimaldab ühel teenusel turvaliselt kasutada teise teenuse andmeid. Kahjuks kasutatakse sellistes standardites palju žargooni ja termineid, mis raskendab nende mõistmist. Selle materjali eesmärk on selgitada, kuidas need töötavad lihtsate illustratsioonide abil (Kas te arvate, et minu joonistused meenutavad laste värvimist? Ahjaa!).
Muide, see juhend on saadaval ka videovormingus:
Daamid ja härrad, tere tulemast: OAuth 2.0
on turbestandard, mis võimaldab ühel rakendusel saada luba teise rakenduse teabele juurde pääseda. Loa väljastamise sammude jada [luba] (Või nõusolekut [nõusolek]) helistavad sageli luba [volitus] или даже delegeeritud volitus [delegeeritud volitus]. Selle standardiga lubate rakendusel teie nimel andmeid lugeda või teise rakenduse funktsioone kasutada ilma parooli andmata. Klass!
Oletame näiteks, et avastate veebisaidi nimega "Päeva õnnetu sõnamäng" [Päeva kohutav sõnamäng] ja otsustas sellel registreeruda, et saada igapäevaseid sõnamänge telefoni tekstisõnumite kujul. Sait meeldis teile väga ja otsustasite seda kõigi oma sõpradega jagada. Lõppude lõpuks meeldivad jubedad sõnamängud kõigile, eks?
"Päeva kahetsusväärne sõnamäng: olete kuulnud mehest, kes kaotas oma vasaku kehapoole? Nüüd on tal alati õigus!” (ligikaudne tõlge, sest originaalil on oma sõnamäng – ca tõlge)
On selge, et igale inimesele kontaktiloendist kirjutamine ei ole valik. Ja kui sa oled vähegi minu moodi, siis annad endast kõik, et vältida asjatut tööd. Õnneks võib päeva kohutav sõnamäng ise kõik teie sõbrad kohale kutsuda! Selleks pead lihtsalt avama juurdepääsu oma kontaktide meilile – sait ise saadab neile kutsed (OAuthi reeglid)!
“Kõik armastavad sõnamängu! - Juba sisse logitud? „Kas soovite lubada veebisaidil Terrible Pun of the Day juurdepääsu oma kontaktide loendile? - Aitäh! Edaspidi saadame iga päev meeldetuletusi kõigile tuttavatele, kuni aegade lõpuni! Sa oled parim sõber!"
- Valige oma meiliteenus.
- Vajadusel minge e-posti saidile ja logige oma kontole sisse.
- Andke oma kontaktidele juurdepääsemiseks luba Päeva kohutavale sõnamängule.
- Naaske päeva kohutava sõnamängu saidile.
Kui muudate meelt, pakuvad OAuthi kasutavad rakendused juurdepääsu ka võimaluse tühistada. Kui olete otsustanud, et te ei soovi enam päeva kohutava sõnamänguga kontakte jagada, võite minna e-posti saidile ja eemaldada sõnamängusait volitatud rakenduste loendist.
OAuth Flow
Oleme just läbi teinud selle, mida tavaliselt nimetatakse voolu [vool] OAuth. Meie näites koosneb see voog nähtavatest sammudest, aga ka mitmest nähtamatust etapist, mille käigus kaks teenust lepivad kokku turvalises teabevahetuses. Eelmises Terrible Pun of the Day näites kasutatakse kõige levinumat OAuth 2.0 voogu, mida tuntakse "volitamiskoodi" voona. ["volitamiskoodi" voog].
Enne OAuthi toimimise üksikasjadesse sukeldumist räägime mõne termini tähendusest.
- Ressursi omanik:
See oled sina! Teile kuuluvad oma mandaadid, andmed ja saate juhtida kõiki tegevusi, mida teie kontodel võidakse teha. - klient:
Rakendus (nt teenus Terrible Pun of the Day), mis soovib juurdepääsu või teatud toiminguid teha Ressursi omanik'а. - Autoriseerimisserver:
Rakendus, mis teab Ressursi omanik'a ja milles u Ressursi omanik'on juba konto. - ressursiserver:
Rakenduse programmeerimisliides (API) või teenus, mis klient nimel soovib kasutada Ressursi omanik'а. - Ümbersuunamise URI:
Link, mis Autoriseerimisserver suunab ümber Ressursi omanikja pärast loa andmist klient'at. Seda nimetatakse mõnikord "tagasihelistamis-URL-iks". - Vastuse tüüp:
Eeldatava teabe tüüp klient. Kõige tavalisem Vastuse tüüp'ohm on kood, see tähendab klient loodab saada Autoriseerimiskood. - Ulatus:
See on vajalike õiguste üksikasjalik kirjeldus klient'y, näiteks andmetele juurdepääsemine või teatud toimingute tegemine. - Nõusolek:
Autoriseerimisserver võtab Õppesuunataotletud klient'om, ja küsib Ressursi omanik'a, kas ta on valmis pakkuma klient'omama vastavaid õigusi. - kliendi ID:
Seda ID-d kasutatakse tuvastamiseks klient'a sisse Autoriseerimisserver'e. - Kliendi saladus:
See on ainult teadaolev parool klient'sina ja Autoriseerimisserver'at. See võimaldab neil privaatselt teavet jagada. - Autoriseerimiskood:
Lühikese kehtivusajaga ajutine kood, mis klient annab Autoriseerimisserver'y vastutasuks Access Token. - Access Token:
Võti, millega klient suhtlemiseks kasutab ressursiserver'om. Omamoodi märk või võtmekaart, mis pakub klientomama luba andmete küsimiseks või toimingute tegemiseks ressursiserverSinu nimel.
Märkus: Mõnikord on autoriseerimisserver ja ressursiserver sama server. Kuid mõnel juhul võivad need olla erinevad serverid, isegi kui need ei kuulu samasse organisatsiooni. Näiteks võib autoriseerimisserver olla kolmanda osapoole teenus, mida ressursiserver usaldab.
Nüüd, kui oleme käsitlenud OAuth 2.0 põhikontseptsioone, pöördume tagasi oma näite juurde ja vaatame lähemalt, mis OAuthi voos toimub.
- Sina, Ressursi omanik, soovite pakkuda teenust Terrible Pun of the Day (klienty) juurdepääs teie kontaktidele, et nad saaksid saata kutseid kõigile teie sõpradele.
- klient suunab brauseri lehele Autoriseerimisserver'a ja lisage päringusse kliendi ID, Ümbersuunamise URI, Vastuse tüüp ja üks või mitu Õppesuuna (load), mida see vajab.
- Autoriseerimisserver kontrollib teid, küsides vajadusel kasutajanime ja parooli.
- Autoriseerimisserver kuvab vormi Nõusolek (kinnitused) koos kõigi nimekirjaga Õppesuunataotletud klient'om. Nõustute või keeldute.
- Autoriseerimisserver suunab teid saidile klient'a, kasutades Ümbersuunamise URI koos Autoriseerimiskood (volituskood).
- klient suhtleb otse Autoriseerimisserver'ohm (brauserist mööda minnes Ressursi omanik'a) ja saadab turvaliselt kliendi ID, Kliendi saladus и Autoriseerimiskood.
- Autoriseerimisserver kontrollib andmeid ja vastab Access Token'om (pääsuluba).
- Nüüd jagab ta klient saab kasutada Access Token päringu saatmiseks ressursiserver kontaktide loendi saamiseks.
Kliendi ID ja saladus
Ammu enne seda, kui lubasite Päeva kohutaval sõnamängul oma kontaktidele juurde pääseda, olid kliendi ja autoriseerimisserver loonud töösuhte. Autoriseerimisserver genereeris kliendi ID ja kliendi saladuse (mõnikord nimetatakse seda App ID и Rakenduse saladus) ja saatis need kliendile edasiseks suhtluseks OAuthis.
"- Tere! Tahaksin teiega koostööd teha! - Muidugi, see pole probleem! Siin on teie kliendi ID ja saladus!
Nimi vihjab, et kliendisaladust tuleb hoida saladuses, et seda teaksid ainult klient ja autoriseerimisserver. Lõppude lõpuks kinnitab autoriseerimisserver just tema abiga Kliendi tõde.
Kuid see pole veel kõik... Tere tulemast OpenID Connecti!
OAuth 2.0 on mõeldud ainult volitus - võimaldada juurdepääsu andmetele ja funktsioonidele ühest rakendusest teise. (OIDC) on OAuth 2.0 peal olev õhuke kiht, mis lisab kontole sisse logitud kasutaja sisselogimis- ja profiiliandmed. Sisselogimisseansi korraldamist nimetatakse sageli autentimine [autentimine]ja teavet süsteemi sisse logitud kasutaja kohta (nt umbes Ressursi omanik'e), — isiklikud andmed [identiteet]. Kui autoriseerimisserver toetab OIDC-d, nimetatakse seda mõnikord ka kui isikuandmete pakkuja [identiteedi pakkuja]sest see annab klient'teavet selle kohta Ressursi omanik'e.
OpenID Connect võimaldab rakendada stsenaariume, kus ühte sisselogimist saab kasutada mitmes rakenduses – seda lähenemist tuntakse ka kui ühekordne sisselogimine (SSO). Näiteks võib rakendus toetada SSO integreerimist sotsiaalsete võrgustikega, nagu Facebook või Twitter, võimaldades kasutajatel kasutada kontot, mis neil juba on ja mida eelistavad kasutada.
Voog (voog) OpenID Connect näeb välja sama, mis OAuthi puhul. Ainus erinevus seisneb selles, et esmases taotluses kasutatakse konkreetset ulatust openid, - A klient lõpuks meeldib Access TokenJa ID-märk.
Nii nagu OAuthi voos, Access Token OpenID Connectis on see väärtus, mis pole selge klient'at. Vaatepunktist klient'а Access Token tähistab tähemärkide jada, mis edastatakse koos iga päringuga ressursiserver'y, mis määrab, kas märk on kehtiv. ID-märk esindab täiesti erinevat asja.
ID Token on JWT
ID-märk on spetsiaalselt vormindatud märgijada, mida tuntakse JSON Web Token või JWT nime all (mõnikord hääldatakse JWT märke nagu "jots"). Välisvaatlejatele võib JWT tunduda arusaamatu jaburana, kuid klient saab JWT-st välja võtta erinevat teavet, nagu ID, kasutajanimi, sisselogimisaeg, aegumiskuupäev ID-märk„a, JWT-d sekkumise katsete olemasolu. Andmed sees ID-märk'a kutsutakse rakendusi [väited].
OIDC puhul on olemas ka standardne viis, mille abil klient võib küsida üksikisiku kohta lisateavet [identiteet] pärit Autoriseerimisserver'a, näiteks e-posti aadress, mis kasutab Access Token.
Lisateave OAuthi ja OIDC kohta
Niisiis vaatasime lühidalt üle, kuidas OAuth ja OIDC töötavad. Kas olete valmis sügavamale kaevama? Siin on täiendavad ressursid, mis aitavad teil OAuth 2.0 ja OpenID Connecti kohta lisateavet saada.
Nagu alati, kommenteerige julgelt. Et olla kursis meie viimaste uudistega, tellige и Okta arendajatele!
PS tõlkijalt
Loe ka meie blogist:
- «";
- «";
- «";
- «'.
Allikas: www.habr.com