Isang Illustrated na Gabay sa OAuth at OpenID Connect

Tandaan. transl.: Ipinapaliwanag ng mahusay na artikulong ito ni Okta kung paano gumagana ang OAuth at OIDC (OpenID Connect) sa simple at malinaw na paraan. Ang kaalamang ito ay magiging kapaki-pakinabang sa mga developer, system administrator, at maging sa "mga regular na user" ng mga sikat na web application, na malamang ay nakikipagpalitan din ng kumpidensyal na data sa iba pang mga serbisyo.

Sa Panahon ng Bato ng Internet, ang pagbabahagi ng impormasyon sa pagitan ng mga serbisyo ay madali. Ibinigay mo lang ang iyong pag-login at password mula sa isang serbisyo patungo sa isa pa, upang maipasok niya ang iyong account at makatanggap ng anumang impormasyong kailangan niya.

"Ibigay mo sa akin ang iyong bank account." “Nangangako kami na magiging maayos ang lahat sa password at pera. Iyan ay tapat, tapat!" *Hee hee*

Horror! Walang sinuman ang dapat humiling sa isang user na magbahagi ng username at password, mga kredensyal, na may isa pang serbisyo. Walang garantiya na ang organisasyon sa likod ng serbisyong ito ay papanatilihing secure ang data at hindi mangongolekta ng higit pang personal na impormasyon kaysa sa kinakailangan. Maaaring mukhang baliw, ngunit ginagamit pa rin ng ilang app ang kasanayang ito!

Ngayon ay may isang pamantayan na nagbibigay-daan sa isang serbisyo na ligtas na gamitin ang data ng isa pa. Sa kasamaang palad, ang mga naturang pamantayan ay gumagamit ng maraming jargon at termino, na nagpapalubha sa kanilang pag-unawa. Ang layunin ng materyal na ito ay upang ipaliwanag kung paano gumagana ang mga ito gamit ang mga simpleng ilustrasyon (Sa palagay mo ba ang aking mga guhit ay kahawig ng pag-daubing ng mga bata? Oh well!).

Sa pamamagitan ng paraan, ang gabay na ito ay magagamit din sa format ng video:

Mga kababaihan at mga ginoo, maligayang pagdating: OAuth 2.0

OAuth 2.0 ay isang pamantayan sa seguridad na nagpapahintulot sa isang application na makakuha ng pahintulot na ma-access ang impormasyon sa isa pang application. Pagkakasunod-sunod ng mga hakbang para sa pagbibigay ng permit [pahintulot] (O pagsang-ayon [payag]) madalas tumawag awtorisasyon [awtorisasyon] o kahit na itinalagang awtorisasyon [itinalagang awtorisasyon]. Sa pamantayang ito, pinapayagan mo ang isang application na magbasa ng data o gamitin ang mga function ng isa pang application sa ngalan mo nang hindi binibigyan ito ng iyong password. Klase!

Bilang halimbawa, sabihin nating nakatuklas ka ng website na tinatawag na "Unlucky Pun of the Day" [Kakila-kilabot na Pun ng Araw] at nagpasya na magrehistro dito upang makatanggap ng pang-araw-araw na mga puns sa anyo ng mga text message sa telepono. Talagang nagustuhan mo ang site, at nagpasya kang ibahagi ito sa lahat ng iyong mga kaibigan. Sabagay, lahat naman ng tao mahilig sa creepy puns diba?

“Unfortunate pun of the day: Narinig mo ba ang tungkol sa taong nawala ang kaliwang kalahati ng kanyang katawan? Ngayon siya ay palaging tama!" (tinatayang pagsasalin, dahil ang orihinal ay may sariling pun - approx. transl.)

Malinaw na ang pagsulat sa bawat tao mula sa listahan ng contact ay hindi isang opsyon. At, kung ikaw ay kahit kaunti tulad ko, pagkatapos ay gagawin mo ang anumang haba upang maiwasan ang hindi kinakailangang trabaho. Sa kabutihang palad, ang Terrible Pun of the Day ay maaaring mag-imbita ng lahat ng iyong mga kaibigan nang mag-isa! Upang gawin ito, kailangan mo lang magbukas ng access sa email ng iyong mga contact - ang site mismo ay magpapadala sa kanila ng mga imbitasyon (mga panuntunan ng OAuth)!

“Lahat ay mahilig sa puns! - Naka-log in na? “Gusto mo bang payagan ang website ng Terrible Pun of the Day na i-access ang iyong listahan ng contact? - Salamat! Mula ngayon, magpapadala kami ng mga paalala araw-araw sa lahat ng kakilala mo, hanggang sa katapusan ng panahon! Ikaw ang matalik na kaibigan!"

1. Piliin ang iyong serbisyo sa email.
2. Kung kinakailangan, pumunta sa mail site at mag-sign in sa iyong account.
3. Bigyan ng pahintulot ang Terrible Pun of the Day na i-access ang iyong mga contact.
4. Bumalik sa site ng Terrible Pun of the Day.

Kung sakaling magbago ang iyong isip, ang mga application na gumagamit ng OAuth ay nagbibigay din ng paraan upang bawiin ang access. Kapag nagpasya kang hindi mo na gustong magbahagi ng mga contact sa Terrible Pun of the Day, maaari kang pumunta sa mail site at alisin ang pun site mula sa iyong listahan ng mga awtorisadong app.

Daloy ng OAuth

Napagdaanan lang namin ang karaniwang tinatawag daloy [daloy] OAuth. Sa aming halimbawa, ang daloy na ito ay binubuo ng mga nakikitang hakbang, pati na rin ang ilang hindi nakikitang mga hakbang, kung saan ang dalawang serbisyo ay sumasang-ayon sa isang secure na pagpapalitan ng impormasyon. Ang nakaraang halimbawa ng Nakakatakot na Pun of the Day ay gumagamit ng pinakakaraniwang daloy ng OAuth 2.0, na kilala bilang daloy ng "authorization code." [daloy ng "authorization code"].

Bago suriin ang mga detalye kung paano gumagana ang OAuth, pag-usapan natin ang kahulugan ng ilang termino:

• May-ari ng Resource:

  
  
  Ikaw nga! Pagmamay-ari mo ang iyong mga kredensyal, ang iyong data, at kontrolin ang lahat ng aktibidad na maaaring gawin sa iyong mga account.

• Kliente:

  
  
  Isang application (halimbawa, ang Terrible Pun of the Day service) na gustong mag-access o magsagawa ng ilang partikular na pagkilos sa ngalan ng May-ari ng Resource'a.

• Server ng Awtorisasyon:

  
  
  Ang app na nakakaalam May-ari ng Resource'a at kung saan u May-ari ng Resource'a may account na.

• server ng mapagkukunan:

  
  
  Application programming interface (API) o serbisyo na Kliente gustong gamitin sa ngalan May-ari ng Resource'a.

• I-redirect ang URI:

  
  
  Yung link Server ng Awtorisasyon ay magre-redirect May-ari ng Resource'at pagkatapos magbigay ng pahintulot Kliente'sa. Minsan ito ay tinutukoy bilang ang "Callback URL."

• Uri ng Tugon:

  
  
  Ang uri ng impormasyong inaasahang matatanggap Kliente. Ang pinakakaraniwan Uri ng Tugon'ohm ay ang code, iyon ay Kliente inaasahan na makatanggap Code ng Awtorisasyon.

• saklaw:

  
  
  Ito ay isang detalyadong paglalarawan ng mga pahintulot na kinakailangan Kliente'y, gaya ng pag-access ng data o pagsasagawa ng ilang partikular na pagkilos.

• Pahintulot:

  
  
  Server ng Awtorisasyon tumatagal Saklawhiniling Kliente'om, at nagtatanong May-ari ng Resource'a, handa ba siyang magbigay Kliente'may mga naaangkop na pahintulot.

• customer ID:

  
  
  Ang ID na ito ay ginagamit upang makilala Kliente'a on Server ng Awtorisasyon'e.

• Lihim ng kliyente:

  
  
  Ito ang password na alam lang Klienteikaw at Server ng Awtorisasyon'sa. Pinapayagan silang magbahagi ng impormasyon nang pribado.

• Code ng Awtorisasyon:

  
  
  Pansamantalang code na may maikling panahon ng bisa, na Kliente nagbibigay Server ng Awtorisasyon'y kapalit ng Access Token.

• Access Token:

  
  
  Ang susi na gagamitin ng kliyente upang makipag-usap server ng mapagkukunan'om. Isang uri ng badge o key card na nagbibigay Kliente'may pahintulot na humiling ng data o magsagawa ng mga aksyon sa server ng mapagkukunan'e sa ngalan mo.

Nota: Minsan ang Authorization Server at Resource Server ay iisang server. Gayunpaman, sa ilang mga kaso, maaaring magkaibang mga server ang mga ito, kahit na hindi sila kabilang sa parehong organisasyon. Halimbawa, ang Authorization Server ay maaaring isang third party na serbisyo na pinagkakatiwalaan ng Resource Server.

Ngayong nasaklaw na natin ang mga pangunahing konsepto ng OAuth 2.0, bumalik tayo sa ating halimbawa at tingnang mabuti kung ano ang nangyayari sa daloy ng OAuth.

1. Ikaw, May-ari ng Resource, gusto mong ibigay ang Terrible Pun of the Day na serbisyo (Klientey) access sa iyong mga contact para makapagpadala sila ng mga imbitasyon sa lahat ng iyong mga kaibigan.
2. Kliente nire-redirect ang browser sa page Server ng Awtorisasyon'a at isama sa query customer ID, I-redirect ang URI, Uri ng Tugon at isa o higit pa Saklaw (mga pahintulot) na kailangan nito.
3. Server ng Awtorisasyon nagpapatunay sa iyo, humihingi ng username at password kung kinakailangan.
4. Server ng Awtorisasyon nagpapakita ng isang form Pahintulot (mga kumpirmasyon) na may listahan ng lahat Saklawhiniling Kliente'om. Sumasang-ayon ka o tumanggi.
5. Server ng Awtorisasyon nire-redirect ka sa site Kliente'a, gamit I-redirect ang URI may Code ng Awtorisasyon (code ng pahintulot).
6. Kliente direktang nakikipag-ugnayan sa Server ng Awtorisasyon'ohm (pag-bypass sa browser May-ari ng Resource'a) at ligtas na nagpapadala customer ID, Lihim ng kliyente и Code ng Awtorisasyon.
7. Server ng Awtorisasyon sinusuri ang data at tumugon sa Access Token'om (token sa pag-access).
8. ngayon Kliente maaaring gamitin Access Token para magpadala ng kahilingan sa server ng mapagkukunan para makakuha ng listahan ng mga contact.

Client ID at Lihim

Matagal bago mo pinahintulutan ang Terrible Pun of the Day na i-access ang iyong mga contact, ang Client at Authorization Server ay nagtatag ng isang gumaganang relasyon. Binuo ng Authorization Server ang Client ID at Client Secret (minsan ay tinutukoy bilang ID ng app и Lihim ng App) at ipinadala ang mga ito sa Kliyente para sa karagdagang pakikipag-ugnayan sa loob ng OAuth.

"- Kamusta! Gusto kong makatrabaho ka! - Oo naman, hindi problema! Narito ang iyong Client ID at Secret!”

Ang pangalan ay nagpapahiwatig na ang Client Secret ay dapat na panatilihing lihim upang ang Client at Authorization Server lamang ang nakakaalam nito. Pagkatapos ng lahat, ito ay sa kanyang tulong na ang Authorization Server ay nagpapatunay sa katotohanan ng Kliyente.

Ngunit hindi lang iyon... Mangyaring tanggapin ang OpenID Connect!

Ang OAuth 2.0 ay idinisenyo lamang para sa awtorisasyon - upang magbigay ng access sa data at mga function mula sa isang application patungo sa isa pa. OpenID Connect (OIDC) ay isang manipis na layer sa itaas ng OAuth 2.0 na nagdaragdag ng mga detalye sa pag-login at profile ng user na naka-sign in sa account. Ang organisasyon ng isang session sa pag-login ay madalas na tinutukoy bilang pagpapatunay [authentication], at impormasyon tungkol sa user na naka-log in sa system (i.e. tungkol sa May-ari ng Resource'e), - personal na data [pagkakakilanlan]. Kung sinusuportahan ng Authorization Server ang OIDC, minsan ito ay tinutukoy bilang tagapagbigay ng personal na data [tagapagbigay ng pagkakakilanlan]dahil nagbibigay ito Kliente'may impormasyon tungkol sa May-ari ng Resource'e.

Binibigyang-daan ka ng OpenID Connect na magpatupad ng mga sitwasyon kung saan ang isang pag-login ay maaaring gamitin sa maramihang mga application - ang diskarteng ito ay kilala rin bilang solong pag-sign-on (SSO). Halimbawa, maaaring suportahan ng isang application ang SSO integration sa mga social network gaya ng Facebook o Twitter, na nagpapahintulot sa mga user na gumamit ng account na mayroon na sila at mas gustong gamitin.

Ang daloy (daloy) na OpenID Connect ay kamukha ng sa kaso ng OAuth. Ang pagkakaiba lang ay sa pangunahing kahilingan, ang partikular na saklaw na ginamit ay openid, - A Kliente sa huli ay nagkakagusto Access TokenAt Token ng ID.

Tulad ng sa daloy ng OAuth, Access Token sa OpenID Connect, ito ay ilang halaga na hindi malinaw Kliente'sa. Mula sa pananaw Kliente'a Access Token kumakatawan sa isang string ng mga character na ipinapasa kasama ng bawat kahilingan sa server ng mapagkukunan'y, na tumutukoy kung wasto ang token. Token ng ID kumakatawan sa isang ganap na naiibang bagay.

Ang ID Token ay isang JWT

Token ng ID ay isang espesyal na na-format na string ng mga character na kilala bilang JSON Web Token o JWT (minsan ang mga JWT token ay binibigkas tulad ng "jots"). Para sa mga tagamasid sa labas, ang JWT ay maaaring mukhang hindi maintindihan na walang kwenta, ngunit Kliente maaaring kunin ang iba't ibang impormasyon mula sa JWT, tulad ng ID, username, oras ng pag-login, petsa ng pag-expire Token ng ID'a, ang pagkakaroon ng mga pagtatangka na makagambala sa JWT. Data sa loob Token ng IDTinatawag si 'a mga aplikasyon [claims].

Sa kaso ng OIDC, mayroon ding karaniwang paraan kung saan Kliente maaaring humiling ng karagdagang impormasyon tungkol sa indibidwal [pagkakakilanlan] mula sa Server ng Awtorisasyon'a, halimbawa, isang email address na gumagamit Access Token.

Matuto pa tungkol sa OAuth at OIDC

Kaya, maikling sinuri namin kung paano gumagana ang OAuth at OIDC. Handa nang maghukay ng mas malalim? Narito ang mga karagdagang mapagkukunan upang matulungan kang matuto nang higit pa tungkol sa OAuth 2.0 at OpenID Connect:

• Ano ba ang OAuth?
• Walang Nagmamalasakit sa OAuth o OpenID Connect
• Ipatupad ang OAuth 2.0 Authorization Code na may PKCE Flow
• Ano ang Uri ng Grant ng OAuth 2.0?
• OAuth 2.0 Mula sa Command Line
• Bumuo ng Secure Node.js App gamit ang SQL Server

Gaya ng nakasanayan, huwag mag-atubiling magkomento. Upang manatiling napapanahon sa aming pinakabagong balita, mag-subscribe sa kaba и YouTube Okta para sa mga developer!

PS mula sa tagasalin

Basahin din sa aming blog:

• «Ang ABC ng Seguridad sa Kubernetes: Authentication, Authorization, Auditing";
• «Mga User at Authorization RBAC sa Kubernetes";
• «33+ tool sa seguridad ng Kubernetes";
• «Seguridad para sa mga lalagyan ng Docker'.

Pinagmulan: www.habr.com