Illustreeritud juhend OAuth'i ja OpenID Connect'i kohta

Märk. tõlge.: Selles suurepärases materjalis räägib ettevõte Okta lihtsalt ja selgelt OAuth-i ja OIDC (OpenID Connect) tööpõhimõtetest. Need teadmised on kasulikud arendajatele, süsteemiadministraatoritele ja isegi tavakasutajatele, kes kasutavad populaarseid veebirakendusi ja jagavad tõenäoliselt ka tundlikke andmeid teiste teenustega.

Interneti „kiviajastu“ ajal oli teenuste vahel teabe jagamine lihtne. Sa andsid lihtsalt oma kasutajanime ja parooli ühe teenuse jaoks teisele, et see saaks siseneda sinu kontole ja saada vajaliku teabe.

„Kasutage oma pangakontot.“ — „Me lubame, et parooliga ja rahaga on kõik korras. Ausõna!“ *hee-hee*

Jube! Keegi ei tohi kunagi nõuda kasutajalt, et ta jagaks oma kasutajanime ja parooli, tema kontod, teise teenusega. Ei mingit garantiid, et selle teenuse taga olev organisatsioon hoiab andmeid turvaliselt ega kogu rohkem isiklikku teavet, kui on vajalik. See võib tunduda metsikuna, kuid mõned rakendused kasutavad endiselt selliseid tavasid!

Täna on olemas ühtne standard, mis võimaldab ühel teenusel turvaliselt kasutada teise andmeid. Kahjuks kasutavad sellised standardid hulga žargooni ja termineid, mis muudavad nende mõistmise keeruliseks. Selle materjali eesmärk on illustreerida, kuidas need töötavad lihtsate jooniste abil (Kas arvad, et mu joonistused näevad välja nagu laste sodimine? No ja siis!).

Muide, see juhend on saadaval ka videoformaatis:

Daamid ja härrad, tutvustame: OAuth 2.0

OAuth 2.0 — see on turvastandard, mis võimaldab ühel rakendusel saada luba teise rakenduse teabele juurdepääsuks. Luba väljastamise järjekord [permission] (või nõusolek [consent]) nimetatakse sageli volitamiseks [authorization] või isegi delegeeritud volitamiseks [delegated authorization]. Selle standardiga annate rakendusele õiguse lugeda andmeid või kasutada teise rakenduse funktsioone teie nimel, paljastamata oma parooli. Lahe!

Näiteks kujutame ette, et leidsid veebisaidi nimega „Tänane kohutav sõnamäng” [Terrible Pun of the Day] otsustav ja registreeritud sellel, et saada igapäevaselt nalju tekstisõnumite kaudu oma telefonile. Veebisait meeldis teile väga ja soovisite seda kõigile tuttavatele jagada. Lõppude lõpuks meeldivad kõikidele kohutavad naljad, eks ole?

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

On selge, et iga inimesele kontaktide loendis kirja kirjutamine ei ole variant. Ja kui te olete vähemalt natuke minu moodi, siis teete kõik selleks, et vältida liigset tööd. Õnneks võib Terrible Pun of the Day ise teie kõigile sõpradele kutse saata! Selleks tuleb vaid anda sellele juurdepääs kontaktide e-posti aadressidele — veebisait saadab neile ise kutseid (OAuth on kuningas)!

«Kohutavad naljad meeldivad kõigile! — Kas olete juba sisse logitud? — Kas soovite anda Terrible Pun of the Day-le juurdepääsu kontaktide loetulele? — Aitäh! Nüüd saadame me iga päev meeldetuletusi kõigile, keda tunnete, igavesti! Te olete parim sõber!»

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

Kui muudate meelt, pakuvad OAuth'i kasutavad rakendused ka võimalust juurdepääsu tühistamiseks. Otsustades, et te ei soovi enam kontakte Terrible Pun of the Day'ga jagada, saate minna e-posti saidile ja eemaldada naljade sait autoriseeritud rakenduste loendist.

OAuth voog

Just läbisime selle, mida tavaliselt nimetatakse vooks [flow] OAuth. Meie näites koosneb see voog nähtavatest sammudest ning mitmest nähtamatust sammust, mille käigus kaks teenust lepivad kokku teabe turvalises jagamises. Varasemas näites Terrible Pun of the Day's kasutatakse kõige levinumat OAuth 2.0 voogu, mida tuntakse "autentimisnäidatud koodi" voona. [«authorization code» flow].

Enne kui süveneme OAuth'i töödetailsse, räägime mõnede terminite tähendusest:

• Ressursi omanik:

  
  
  See oled sina! Sa oled oma mandaadi omanik, oma andmete haldaja ja vastutad kõigi toimingute eest, mis võivad sinu kontodega seotud olla.

• Kliendi:

  
  
  Rakendus (näiteks teenus Terrible Pun of the Day), mis soovib pääseda juurde või teha teatud toiminguid Ressursi omaniknimel.

• Autoriseerimisserver:

  
  
  Rakendus, mis teab Ressursi omanikning millel on Ressursi omanikjuba konto.

• Ressursside server:

  
  
  Rakendusprogrammi liides (API) või teenus, mida Kliendi soovitakse kasutada Ressursi omaniknimel.

• Redirect URI:

  
  
  Link, mille kaudu Autoriseerimisserver suunatakse Ressursi omanikpärast loa andmist Kliendi. Mõnikord nimetatakse seda „Tagasipöördumise URL-iks” (Callback URL).

• Response Type:

  
  
  Teave, mida oodatakse Kliendi. Kõige levinum Response Typetüüp on kood, see tähendab Kliendi et oodatakse Autoriseerimiskood.

• Ulatus:

  
  
  See on üksikasjalik kirjeldus lubadest, mis on vajalikud Kliendi, nagu juurdepääs andmetele või teatud toimingute tegemine.

• Nõusolek:

  
  
  Autoriseerimisserver võtab Skopid, mida küsitakse Kliendija küsib Ressursi omanikkas ta on valmis Kliendivastavad õigused.

• Kliendi ID:

  
  
  See ID kasutatakse Kliendituvastamiseks Autoriseerimisserversüsteemis.

• Kliendi saladus:

  
  
  See on parool, mis on teada ainult Kliendija Autoriseerimisserver. See võimaldab neil teavet konfidentsiaalselt vahetada.

• Autoriseerimiskood:

  
  
  Ajutine kood, millel on lühike kehtivusaeg, mille Kliendi pakub Autoriseerimisserversaab vahetada Access Tokeni vastu..

• Access Tokeni vastu.:

  
  
  Klahv, mida klient kasutab ühenduse saamiseks Ressursside server‘iga. Teatud tüüpi käepide või võtmekaart, mis annab Kliendi‘ile õiguse andmete taotlemiseks või toimingute tegemiseks Ressursside server‘i nimel.

Märkus: mõnikord on Autoriseerimise Server ja Ressursside Server sama server. Kuid mõnel juhul võivad need olla erinevad serverid, mis ei kuulugi sama organisatsiooni. Näiteks võib Autoriseerimise Server olla kolmanda osapoole teenus, millele Ressursside Server usaldab.

Nüüd, kui oleme tutvunud OAuth 2.0 põhikontseptsioonidega, pöördume tagasi meie näite juurde ja vaatame lähemalt, mis toimub OAuth voos.

1. Teie, Ressursi omaniksoovite anda Terrible Pun of the Day (Kliendi‘ile) juurdepääsu oma kontaktidele, et see saaks saata kutseid kõigile teie sõpradele.
2. Kliendi suunab brauseri lehele Autoriseerimisserver‘i ja lisab päringule Kliendi ID, Redirect URI, Response Type ja ühe või mitu Skopid (luba), mida ta vajab.
3. Autoriseerimisserver kontrollib teid, küsides vajadusel sisse logimist ja parooli.
4. Autoriseerimisserver kuvab vormi Nõusolek (kinnitamiseks) koos loetelu kõigist Skopid, mida on taotlenud Kliendi‘. Te nõustute või keeldute.
5. Autoriseerimisserver suunab teid 'i veebisaidile, kasutades Kliendikoos Redirect URI (autoriseerimiskoodiga). Autoriseerimiskood ühendab otse
6. Kliendi otseselt ühendub Autoriseerimisserver‘om (brauserist mööda Ressursi omanik‘a) ja edastab turvaliselt Kliendi ID, Kliendi saladus ja Autoriseerimiskood.
7. Autoriseerimisserver kontrollib andmeid ja vastab Access Tokeni vastu.‘om (juurdepääsutoken).
8. Nüüd Kliendi võib kasutada Access Tokeni vastu. päringu saatmiseks Ressursside server et saada kontaktide nimekiri.

Klient ID ja Salajasuset

Enne seda, kui andsite Terrible Pun of the Day-le juurdepääsu kontaktidele, loodi Kliendi ja Autentimisserveri vahel tööaluseid suhteid. Autentimisserver genereeris Klient ID ja Klient Salajasuse (mõnikord nimetatakse neid Rakenduse ID ja Rakenduse Salajasus) ja saatis need Klient’ile edasiseks suhtlemiseks OAuth-i raames.

«— Tere! Ma tahaksin sinuga koostööd teha! — Pole probleemi! Siin on sinu Klient ID ja Salajasus!»

Nimi vihjab sellele, et Klient Salajasus peab olema saladuses, nii et seda teavad ainult Klient ja Autentimisserver. Just tema abil Autentimisserver kinnitab Klient’ide tõelisust.

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

OAuth 2.0 on välja töötatud ainult autoriseerimiseks — et võimaldada juurdepääsu andmetele ja funktsioonidele ühe rakenduse poolt teisele. OpenID Connect (OIDC) on OAuth 2.0 peal õhuke kiht, mis lisab teavet kasutaja sisselogimise ja profiili kohta, kes on sisse logitud konto. Sisselogimisseansi korraldamist nimetatakse sageli autentimiseks [authentication], ja teave kasutaja kohta, kes on sisse logitud (st Ressursi omanik‘e), — isiklike andmete [identity]. Kui autoriseerimisteenus toetab OIDC, nimetatakse seda mõnikord isiklike andmete teenusepakkujaks [identity provider], kuna see pakub Kliendi‘le teavet Ressursi omaniksüsteemis.

OpenID Connect võimaldab realiseerida stsenaariume, kus ühtset sisselogimist saab kasutada mitmes rakenduses — see lähenemine on tuntud ka kui ühtne sisselogimine (SSO). Näiteks võib rakendus toetada SSO-integratsiooni sotsiaalmeedia platvormidega, nagu Facebook või Twitter, võimaldades kasutajatel kasutada juba olemasolevat ja eelistatud kontot.

OpenID Connecti voog (flow) näeb välja sarnane nagu OAuth puhul. Ainuke erinevus on see, et esialgses päringus kasutatav konkreetne scope on openid, — ja Kliendi lõppkokkuvõttes saadakse nii Access Tokeni vastu., kui ka ID Token.

Sarnaselt OAuth voogule, Access Tokeni vastu. OpenID Connectis — see on mingi väärtus, mis ei ole mõistetav Kliendi‘le. Vaatenurgast Kliendi‘st Access Tokeni vastu. on see mingi sümbolite string, mis edastatakse koos iga päringuga Ressursside server‘le, ja see määrab, kas token on kehtiv. ID Token on täiesti midagi muud.

ID Token on JWT

ID Token — on erilise vormindusega sümbolite rida, mida tuntakse kui JSON Web Token või JWT (mõnikord hääldatakse JWT-sid kui „jots”). Kolmandatele isikutele võib JWT tunduda arusaamatu abrakadabra, kuid Kliendi võib JWT-st välja tõmmata erinevat teavet, nagu ID, kasutajanimi, konto sisenemise aeg, kehtivuse lõppemise aeg ID Tokenja võimalike sekkumiskatsete kohta JWT-sse. Andmed ID Tokenselles on [claims].

OIDC puhul on ka standardne viis, kuidas Kliendi võib küsida täiendavat teavet isiku kohta [identity] alates Autoriseerimisservernäiteks e-posti aadress, kasutades Access Tokeni vastu..

Täiendavad üksikasjad OAuth ja OIDC kohta

Nii oleme lühidalt käsitlenud OAuth ja OIDC toimimist. Kas olete valmis sügavamale kaevama? Siin on täiendavad ressursid, mis aitavad rohkem teada saada OAuth 2.0 ja OpenID Connecti kohta:

• Mis asi on OAuth?
• Kedagi ei koti OAuth ega OpenID Connect
• Rakenda OAuth 2.0 autoriseerimiskoodi koos PKCE vooguga
• Mis on OAuth 2.0 toetustüüp?
• OAuth 2.0 käsurealt
• Ehita turvaline Node.js rakendus SQL Serveriga

Nagu tavaliselt, ärge kartke kommenteerida. Et olla kursis meie uusimate uudistega, tellige Twitter ja YouTube Okta arendajate ettevõtte uudiskiri!

P.S. tõlkija märkused

Lugege ka meie blogist:

• «Kubernetes'e turvaabitus: autentimine, autoriseerimine, audit»;
• «Kasutajad ja autoriseerimine RBAC Kuberneteses»;
• «33+ Kubernetes'i turbe tööriista»;
• «Turvalisus Docker konteinerite jaoks».

Allikas: habr.com