Illustreeritud juhend OAuth ja OpenID Connect kohta

Märkus tõlke kohta.: Selles suurepärases materjalis räägib Okta selgelt ja arusaadavalt OAuthi ja OIDC (OpenID Connect) toimimise põhimõtetest. Need teadmised on kasulikud arendajatele, süsteemiadministraatoritele ja isegi tavakasutajatele, kes kasutavad populaarseid veebirakendusi, mis tõenäoliselt jagavad ka oma konfidentsiaalseid andmeid teiste teenustega.

Interneti „kivikodus” oli teabe jagamine teenuste vahel lihtne. Antid lihtsalt oma sisselogimise ja parooli ühest teenusest teise, et nad saaksid pääseda sinu kontole ja saada vajalikku teavet.

„Andke oma pangakonto.” - „Lubame, et paroolide ja rahaga on kõik korras. Tõesti, ausalt!” *haha*

Jube! Ükski organisatsioon ei tohi kunagi nõuda, et kasutaja jagaks oma sisselogimisandmeid andmeid, mis on seotud teiste teenustega. Pole mingeid garantii, et see teenus, mille eest see organisatsioon seisab, hoiab andmeid turvaliselt ja ei kogu rohkem isiklikku teavet, kui vajalik. See võib tunduda märkamatuna, kuid mõned rakendused kasutavad endiselt sellist praktikat!

Tänapäeval on olemas ühtne standard, mis võimaldab ühel teenusel turvaliselt kasutada teiste andmeid. Kahjuks sisaldavad sellised standardid palju žargooni ja termineid, mis muudavad nende mõistmise keeruliseks. Selle materjali eesmärk on kasutada lihtsaid illustratsioone, et selgitada, kuidas need toimivad (Kas arvate, et mu joonistused meenutavad laste joonistusi? No ja mis siis!).

Muide, see juhend on saadaval ka videoformaadis:

Daamid ja härrad, tervitage: OAuth 2.0

OAuth 2.0 on turstandard, mis võimaldab ühel rakendusel saada volitusi teise rakenduse teabe kasutamiseks. Luba andmise protseduur [permission] (või nõusolek [consent]) nimetatakse sageli autoriseerimiseks [authorization] või isegi delegeeritud autoriseerimiseks [delegated authorization]. Selle standardi abil lubate rakendusel lugeda andmeid või kasutada teise rakenduse funktsioone teie nimel, ilma et jagaksite selle parooli. Lahe!

Näiteks kujuta ette, et oled leidnud veebisaidi nimega „Päeva kohutav sõnamäng” [Terrible Pun of the Day] ja registreeriti seal, et saada iga päev sõnademängusid tekstisõnumitena oma telefonile. Hindate seda veebisaiti väga ja otsustasite jagada seda kõigiga, keda tunnete. Saame aru, et kohutavad sõnademängud meeldivad kõigile, kas pole?

«Päeva ebaõnnestunud sõnademäng: Kas olete kuulnud mehest, kes kaotas vasaku keha poole? Nüüd on ta alati parem!» (tõlge on umbkaudne, sest originaalis on oma sõnamäng — toim.)

On selge, et igale kontaktloendi isikule kirjutamine ei ole variant. Ja kui te natukenegi sarnanete mulle, siis teete kõik, et vältida ülemäärast tööd. Õnneks saab Terrible Pun of the Day ise kutsuda kõiki teie sõpru! Selleks tuleb lihtsalt avada rakendusele juurdepääs oma kontaktide e-posti aadressile — veebisait saadab neile ise kutseid (OAuth juhib)!

«Kõik armastavad sõnademänge! — Kas olete juba sisse loginud? — Kas soovite avada Terrible Pun of the Day lehele juurdepääsu kontaktide loetellu? — Aitäh! Nüüd saadame igapäevaselt meeldetuletusi kõigile, keda te tunnete, igavesti! Te olete parim sõber!»

1. Valige oma e-posti teenus.
2. Vajadusel minge e-posti lehele ja logige oma kontole sisse.
3. Andke Terrible Pun of the Day lehele luba kontaktidele juurdepääsuks.
4. Naaske Terrible Pun of the Day lehele.

Juhul kui te ümber mõtleks, pakuvad OAuth-i rakendused samuti võimalust juurdepääsu tühistamiseks. Kui olete otsustanud, et te ei soovi enam oma kontaktidega Terrible Pun of the Day jagada, võite minna e-posti lehele ja eemaldada sõnademänge sisaldav veebisait autoriseeritud rakenduste loendist.

OAuth voog

Just äsja läbisime selle, mida tavaliselt nimetatakse voog [flow] OAuth. Meie näites koosneb see voog nähtavatest sammudest ning mitmest nähtamatust, mille jooksul kaks teenust lepivad kokku teabe turvalises vahetamises. Eelnevas näites Terrible Pun of the Day korraldatakse kõige levinum OAuth 2.0 voog, mida tuntakse kui "autoriseerimiskoodi" voog [„authorization code“ flow].

Enne kui sukeldume OAuth tööpõhimõtete detaljidesse, räägime mõnedest mõistetest:

• Ressursi omanik:

  
  
  See olete teie! Te omate oma mandaate, oma andmeid ja haldate kõiki tegevusi, mis võivad toimuda teie kontodega.

• Klient:

  
  
  Rakendus (nt teenus Terrible Pun of the Day), mis soovib pääseda juurde või teostada teatud toiminguid {client_name} nimel. Ressursi omanik‘le.

• Autoriseerimise server:

  
  
  Rakendus, mis teab Ressursi omanik‘st ja millel on Ressursi omanik‘l juba konto.

• Resursside server:

  
  
  Rakenduste programmeerimise liides (API) või teenus, mida Klient soovib kasutada {client_name} nimel. Ressursi omanik‘le.

• Suunamis-URI:

  
  
  Link, kuhu Autoriseerimise server suunatakse Ressursi omanik‘le pärast volituste andmist Klient‘le. Mõnikord nimetatakse seda ka 'Tagastamis-URL' ('Callback URL').

• Vastusetüüp:

  
  
  Teave, mida oodatakse saavat Klient. Levinum Vastusetüüp‘st on kood, mis tähendab Klient et plaanitakse saada Autoriseerimis kood.

• Ulatus:

  
  
  See on detailne kirjeldus lubadest, mis on vajalikud Klient‘le, näiteks andmete juurde pääsemiseks või teatud toimingute teostamiseks.

• Nõusolek:

  
  
  Autoriseerimise server võtab Skopid, mida küsib Klient‘lt, ja küsib Ressursi omanik‘lt, kas ta on valmis andma Klient‘le vastavad õigused.

• Client ID:

  
  
  See ID kasutatakse Klient‘t tuvastamiseks Autoriseerimise server‘s.

• Kliendisaladus:

  
  
  See on parool, mis on tuntud ainult Klient‘le ja Autoriseerimise server‘le. See võimaldab neil konfidentsiaalselt teavet vahetada.

• Autoriseerimis kood:

  
  
  Ajutine kood lühikese kehtivusajaga, mida Klient pakub Autoriseerimise server‘lt vahetatakse Ligipääsutoken.

• Ligipääsutoken:

  
  
  Võti, mida klient kasutab suhtlemiseks Resursside server‘ga. See on nagu badge või juurdepääsukaart, mis annab Klient‘le õiguse pärida andmeid või teostada toiminguid Resursside server‘s {client_name} nimel.

Märkus: mõnikord on autoriseerimise server ja ressursserver sama server. Siiski võivad nad olla ka erinevad serverid, mis ei kuulu isegi samasse organisatsiooni. Näiteks autoriseerimise server võib olla kolmas osaliste teenus, mida usaldab ressursserver.

Nüüd, kui oleme tutvunud OAuth 2.0 põhikontseptsioonidega, vaatame tagasi meie näitele ja uurime üksikasjalikult, mis toimub OAuth voo käigus.

1. Teie, Ressursi omaniksoovite anda teenusele Terrible Pun of the Day ({client_name}) ligipääsu oma kontaktidele, et nad saaksid saata kutseid kõigile teie sõpradele.Klientsuunab brauseri lehele
2. Klient ‘le ja sisaldab päringus Autoriseerimise serverja ühte või mitut Client ID, Suunamis-URI, Vastusetüüp (luba), mida tal on vaja. Skopid kontrollib teid, küsides vajadusel sisselogimist ja parooli.
3. Autoriseerimise server kuvatakse vorm
4. Autoriseerimise server (kinnitada) kõigi seas Nõusolek , mida küsib Skopid‘lt. Te nõustute või keeldute. Klientsuunab teid saidile
5. Autoriseerimise server ‘le, kasutades Klient(autoriseerimiskoodi). Suunamis-URI koos Autoriseerimis kood otseteed ühendab
6. Klient ‘ga (brauseri vahele jätmine Autoriseerimise server‘st) ja saadab turvaliselt. Ressursi omanik‘а) и безопасно отправляет Client ID, Kliendisaladus ja Autoriseerimis kood.
7. Autoriseerimise server kontrollib andmeid ja vastab Ligipääsutoken’ga (juurdepääsu tokeniga).
8. Nüüd Klient üht privaate võtit, olenemata sellest, millist juhuslikustatud versiooni tema avalikust võtme kasutati krüpteerimiseks. Ligipääsutoken päringu saatmiseks Resursside server eesmärgiga saada kontaktide nimekiri.

Kliendi ID ja Salajane

Aastas enne, kui te lubasite Terrible Pun of the Day'il pääseda kontaktidele, kliendil ja autoriseerimise serveril loodi tööalased suhted. Autoriseerimise server genereeris Kliendi ID ja Kliendi Saladuse (mõnikord nimetatakse neid ka Rakenduse ID ja Rakenduse Salajane) ja saatis need kliendile edaspidiseks suhtlemiseks OAuth raames.

„— Tere! Ma tahaksin teiega koostööd teha! — Pole probleemi! Siin on sinu Kliendi ID ja Salajane!”

Nimi viitab sellele, et Kliendi Saladust tuleks hoida saladuses, et seda teaksid ainult Klient ja Autoriseerimise Server. Just selle abil Autoriseerimise Server kinnitab Kliendi tõelisust.

Aga see pole veel kõik… Palun tervitage OpenID Connect'i!

OAuth 2.0 on loodud ainult volitamiseks — andmete ja funktsioonide andmiseks ühest rakendusest teise. OpenID Connect (OIDC) — see on õhuke kiht OAuth 2.0 kohal, mis lisab teavet kasutaja sisselogimise ja profiili kohta, kes on oma kontole sisse loginud. Sisselogimise sessiooni korraldamist nimetatakse sageli autentimiseks [authentication], ja teavet sisseloginud kasutaja kohta (st Ressursi omanik’st), — isikuandmed [identity]. Kui Autoriseerimise Server toetab OIDC-d, nimetatakse seda mõnikord isikuteabe pakkujaks [identity provider], kuna see annab Klient’le teavet Ressursi omanik‘s.

OpenID Connect võimaldab ellu viia stsenaariume, kus ühtset sisselogimist saab kasutada mitmes rakenduses — seda lähenemist tuntakse ka kui ühtne sisselogimine (SSO). Näiteks võib rakendus toetada SSO integreerimist sotsiaalsete võrgustikega, nagu Facebook või Twitter, lubades kasutajatel kasutada juba olemasolevat ja eelistatud kontot.

OpenID Connect’i voog (flow) näeb välja sarnaselt OAuth'iga. Ainuke erinevus seisneb selles, et algses päringus kasutatav konkreetne ulatus (scope) on openid, — ja Klient saab lõpuks nagu Ligipääsutoken, kui ka ID Token.

Nagu ka OAuth'i voos, Ligipääsutoken on OpenID Connect'is - see on mingi väärtus, mida ei mõisteta Klient’le. Kliendi poolelt Klientesindab see teatud sümbolite jada, mis saadetakse koos iga päringuga Ligipääsutoken ’le, ja see määrab, kas token on kehtiv. Resursside serveresindab täiesti muud. ID Token ID Token — see on JWT

— see on eriliselt vormindatud sümbolite jada, tuntud kui JSON Web Token või JWT

ID Token (mõnikord hääldatakse JWT-d kui „jots”) (иногда токены JWT произносят как «jots»). Kolmandatel isikutel võib JWT näida arusaamatu abrakadabra, kuid Klient saab JWT-st erinevat teavet, näiteks ID, kasutajanimi, sisselogimise aeg, kehtivuse lõppkuupäev ID Tokenteatustele sekkumise katsete olemasolust. Andmed sees ID Tokennimetatakse nõudmisteks [claims].

OIDC korral on olemas ka standardne viis, kuidas Klient võib küsida lisateavet isiku kohta [identity] alates Autoriseerimise servernt e-posti aadress, kasutades Ligipääsutoken.

Lisainfot OAuth ja OIDC kohta

Nii, oleme lühidalt üle vaadanud OAuth ja OIDC tööpõhimõtted. Kas olete valmis sügavamale minekuks? Siin on täiendavad ressursid, mis aitavad rohkem teada saada OAuth 2.0 ja OpenID Connecti kohta:

• Mis asi on OAuth?
• Kedagi ei huvita OAuth või OpenID Connect
• Rakendage OAuth 2.0 volituste koodi koos PKCE protsessiga
• Mis on OAuth 2.0 volituste tüüp?
• OAuth 2.0 käsurealt
• Looge turvaline Node.js rakendus SQL Serveriga

Nagu ikka, ärge kartke kommenteerida. Et olla kursis meie viimaste uuendustega, tellige Twitteris ja YouTube Okta arendajate ettevõttelt!

P.S. tõlkijalt

Lugege ka meie blogist:

• «Kubernetes’i turvalisuse abecedaar: autentimine, autoriseerimine, audit»;
• «Kasutajad ja RBAC autoriseerimine Kuberneteses»;
• «33+ Kubernetesi turvalisuse tööriista»;
• «Dockeri konteinerite turvalisus».

Allikas: habr.com