Ілюстраванае кіраўніцтва па OAuth і OpenID Connect

Заўв. перав.: У гэтым выдатным матэрыяле кампаніі Okta проста і наглядна расказваецца аб прынцыпах работы OAuth і OIDC (OpenID Connect). Гэтыя веды будуць карысныя распрацоўнікам, сістэмным адміністратарам і нават "звычайным карыстачам" папулярных вэб-прыкладанняў, якія хутчэй за ўсё таксама абменьваюцца канфідэнцыйнымі дадзенымі з іншымі сэрвісамі.

У "каменным стагоддзі" інтэрнэту дзяліцца інфармацыяй паміж сэрвісамі было лёгка. Вы проста давалі свой лагін і пароль ад аднаго сэрвісу іншаму, каб той увайшоў у ваш уліковы запіс і атрымаў любую неабходную яму інфармацыю.

«Падайце сваю банкаўскую ўліку». - «Абяцаем, што з паролем і грашыма ўсё будзе ў парадку. Вось прамы сумленна-сумленна!» *хі-хі*

Жудасць! Ніхто і ніколі не павінен патрабаваць ад карыстальніка падзяліцца лагінам і паролем, яго уліковымі дадзенымі, з іншым сэрвісам. Няма ніякай гарантыі, што арганізацыя, якая стаіць за гэтым сэрвісам, будзе захоўваць дадзеныя ў бяспецы і не збярэ больш персанальнай інфармацыі, чым трэба. Гэта можа здацца дзікасцю, але некаторыя прыкладанні да гэтага часу ўжываюць падобную практыку!

Сёння ёсць адзіны стандарт, які дазваляе аднаму сэрвісу бяспечна скарыстацца дадзенымі іншага. Нажаль, падобныя стандарты выкарыстаюць масу жарганізмаў і тэрмінаў, што ўскладняе іх разуменне. Мэта гэтага матэрыялу - з дапамогай простых ілюстрацый растлумачыць, як яны працуюць (Думаеце, што мае малюнкі нагадваюць дзіцячую мазню? Ну і добра!).

Між іншым, гэтае кіраўніцтва таксама даступна ў фармаце відэа:

Дамы і спадары, сустракайце: OAuth 2.0

OAuth 2.0 — гэта стандарт бяспекі, які дазваляе аднаму з дадаткам атрымаць дазвол на доступ да інфармацыі ў іншым дадатку. Паслядоўнасць дзеянняў для выдачы дазволу [permission] (Або згоды [consent]) часта называюць аўтарызацыяй [authorization] ці нават дэлегаванай аўтарызацыяй [delegated authorization]. З дапамогай гэтага стандарту вы дазваляеце з дадаткам лічыць дадзеныя або выкарыстоўваць функцыі іншага прыкладання ад вашага імя, не паведамляючы яму свой пароль. Клас!

У якасці прыкладу ўявім, што вы знайшлі сайт з назвай «Няўдалы каламбур дня» [Terrible Pun of the Day] і вырашылі зарэгістравацца на ім, каб штодня атрымліваць каламбуры ў выглядзе тэкставых паведамленняў на тэлефон. Сайт вам вельмі спадабаўся і вы вырашылі падзяліцца ім з усімі знаёмымі. Бо жудасныя каламбурчыкі падабаюцца ўсім, ці не так?

«Няўдалы каламбур дня: Чулі пра хлопца, які страціў левую палову цела? Цяпер ён заўсёды мае рацыю!» (пераклад прыкладны, т. к. у арыгінале свая гульня слоў - заўв. перакл.)

Зразумела, што пісаць кожнаму чалавеку з кантакт-ліста не варыянт. І, калі вы хаця б крышачку падобныя на мяне, то пойдзеце на ўсё, каб пазбегнуць лішняй працы. Балазе Terrible Pun of the Day можа сам запрасіць усіх вашых сяброў! Для гэтага толькі трэба адкрыць яму доступ да электроннай пошты кантактаў - сайт сам адправіць ім запрашэння (OAuth руліць)!

«Усе любяць каламбуры! - Ужо залагініліся? - Жадаеце адкрыць доступ сайту Terrible Pun of the Day да спісу кантактаў? - Дзякуй! Цяпер мы кожны дзень будзем слаць напамінкі ўсім, каго вы ведаеце, да сканчэння вякоў! Вы самы лепшы сябар!»

1. Абярыце свой сэрвіс электроннай пошты.
2. Пры неабходнасці перайдзіце на сайт пошты і ўвайдзіце ва ўліковы запіс.
3. Дайце дазвол сайту Terrible Pun of the Day на доступ да кантактаў.
4. Калі ласка, вярніцеся на сайт Terrible Pun of the Day.

У выпадку, калі вы перадумаеце, прыкладанні, якія выкарыстоўваюць OAuth, таксама падаюць спосаб ануляваць доступ. Вырашыўшы, што вы больш не жадаеце дзяліцца кантактамі з Terrible Pun of the Day, вы можаце перайсці на сайт пошты і выдаліць сайт з каламбурамі са спісу аўтарызаваных прыкладанняў.

Струмень OAuth

Толькі што мы прайшлі праз тое, што звычайна называюць патокам [flow] OAuth. У нашым прыкладзе гэты паток складаецца з бачных крокаў, а таксама з некалькіх нябачных крокаў, у рамках якіх два сэрвісы дамаўляюцца аб бяспечным абмене інфармацыяй. У папярэднім прыкладзе з Terrible Pun of the Day выкарыстоўваецца найболей распаўсюджаны струмень OAuth 2.0, вядомы як струмень "з кодам аўтарызацыі" [«authorization code» flow].

Перш чым паглыбіцца ў падрабязнасці працы OAuth, давайце пагаворым аб значэнні некаторых тэрмінаў:

• Resource Owner:

  
  
  Гэта вы! Вы валодаеце сваімі ўліковымі дадзенымі, сваімі дадзенымі і кіруеце ўсімі дзеяннямі, якія могуць быць зроблены з вашымі акаўнтамі.

• Кліент:

  
  
  Дадатак (напрыклад, сэрвіс Terrible Pun of the Day), які хоча атрымаць доступ або выканаць пэўныя дзеянні ад імя Resource Owner'а.

• Authorization Server:

  
  
  Дадатак, якое ведае Resource OwnerТа і ў якім у Resource Owner'а ўжо ёсць уліковы запіс.

• Resource Server:

  
  
  Праграмны інтэрфейс прыкладання (API) або сэрвіс, якім Кліент хоча скарыстацца ад імя Resource Owner'а.

• Redirect URI:

  
  
  Спасылка, па якой Authorization Server перанакіруе Resource Owner'а пасля прадастаўлення дазволу КліентСу. Часам яе завуць "Зваротным URL" ("Callback URL").

• Тып адказу:

  
  
  Тып інфармацыі, якую чакае атрымаць Кліент. Самым распаўсюджаным Тып адказуТым з'яўляецца код, гэта значыць Кліент разлічвае атрымаць Код дазволу.

• Сфера:

  
  
  Гэта падрабязнае апісанне дазволаў, якія патрабуюцца Кліент'у, такія як доступ да дадзеных або выкананне пэўных дзеянняў.

• Згода:

  
  
  Authorization Server бярэ Вобласці, запытаныя КліентТым, і пытаецца ў Resource OwnerТая, ці гатовы той даць Кліент'у адпаведныя дазволы.

• Ідэнтыфікатар кліента:

  
  
  Гэты ID выкарыстоўваецца для ідэнтыфікацыі КліентТая на Authorization ServerГэта.

• Сакрэт кліента:

  
  
  Гэта пароль, які вядомы толькі КліентСу і Authorization ServerСу. Ён дазваляе ім канфідэнцыйна абменьвацца інфармацыяй.

• Код дазволу:

  
  
  Часовы код з невялікім перыядам дзеяння, які Кліент дае Authorization ServerСу ў абмен на Доступ да токена.

• Доступ да токена:

  
  
  Ключ, які кліент будзе выкарыстоўваць для сувязі з Resource ServerТым. Гэткі бэйдж або ключ-карта, які прадстаўляе Кліент'у дазволу на запыт даных або выкананне дзеянняў на Resource ServerГэта ад вашага імя.

Заўвага: часам Authorization Server і Resource Server з'яўляюцца адным і тым жа серверам. Аднак у некаторых выпадках гэта могуць быць розныя серверы, нават не прыналежныя да адной арганізацыі. Напрыклад, Authorization Server можа быць іншым сэрвісам, якому давярае Resource Server.

Цяпер, калі мы азнаёміліся з асноўнымі паняццямі OAuth 2.0, давайце вернемся да нашага прыкладу і падрабязна разгледзім, што адбываецца ў струмені OAuth.

1. Вы, Resource Owner, жадаеце даць сэрвісу Terrible Pun of the Day (Кліент'у) доступ да сваіх кантактаў, каб той мог разаслаць запрашэнні ўсім вашым сябрам.
2. Кліент перанакіроўвае браўзэр на старонку Authorization ServerТая і ўключае ў запыт Ідэнтыфікатар кліента, Redirect URI, Тып адказу і адно ці некалькі Вобласці (дазволаў), якія яму неабходныя.
3. Authorization Server правярае вас, пры неабходнасці запытваючы лагін і пароль.
4. Authorization Server выводзіць форму Згода (пацверджанні) з пералікам усіх Вобласці, запытаных КліентТым. Вы згаджаецеся ці адмаўляецеся.
5. Authorization Server перанакіроўвае вас на сайт КліентТая, выкарыстоўваючы Redirect URI РІРјРμСЃС, Рμ СЃ Код дазволу (кодам аўтарызацыі).
6. Кліент напрамую звязваецца з Authorization ServerТым (у абыход браўзэра Resource Ownerя) і бяспечна адпраўляе Ідэнтыфікатар кліента, Сакрэт кліента и Код дазволу.
7. Authorization Server правярае дадзеныя і адказвае з Доступ да токенаТым (токенам доступу).
8. Цяпер Кліент можа выкарыстоўваць Доступ да токена для адпраўкі запыту на Resource Server з мэтай атрымаць спіс кантактаў.

Client ID і Secret

Задоўга да таго, як вы дазволілі Terrible Pun of the Day атрымаць доступ да кантактаў, Client і Authorization Server устанавілі працоўныя адносіны. Authorization Server згенераваў Client ID і Client Secret (часам іх завуць ідэнтыфікатар прыкладання и Сакрэт прыкладання) і адправіў іх Client'у для далейшага ўзаемадзеяння ў рамках OAuth.

«- Прывітанне! Я хацеў бы працаваць з табой! - Ды не пытанне! Вось твае Client ID і Secret!»

Назва намякае, што Client Secret павінен трымацца ў таямніцы, каб яго ведалі толькі Client і Authorization Server. Бо менавіта з яго дапамога Authorization Server пацвярджае сапраўднасць Client'а.

Але гэта яшчэ не ўсё… Калі ласка, павітайце OpenID Connect!

OAuth 2.0 распрацаваны толькі для аўтарызацыі - Для прадастаўлення доступу да дадзеных і функцый ад аднаго прыкладання іншаму. OpenID Connect (OIDC) - гэта тонкі пласт па-над OAuth 2.0, які дадае звесткі аб лагіне і профілі карыстальніка, які ўвайшоў ва ўліковы запіс. Арганізацыю лагін-сесіі часта называюць аўтэнтыфікацыяй [authentication], а інфармацыю аб карыстальніку, які ўвайшоў у сістэму (г.зн. аб Resource OwnerС'е), - асабістымі дадзенымі [identity]. Калі Authorization Server падтрымлівае OIDC, яго часам завуць пастаўшчыком асабістых дадзеных [identity provider], паколькі ён дае Кліент'у інфармацыю аб Resource OwnerГэта.

OpenID Connect дазваляе рэалізоўваць сцэнары, калі адзіны лагін можна выкарыстоўваць у мностве прыкладанняў, - гэты падыход таксама вядомы як адзіны ўваход (SSO). Напрыклад, прыкладанне можа падтрымліваць SSO-інтэграцыю з сацыяльнымі сеткамі, такімі як Facebook або Twitter, дазваляючы карыстальнікам выкарыстоўваць уліковы запіс, які ў іх ужо ёсць і якую яны аддаюць перавагу выкарыстоўваць.

Струмень (flow) OpenID Connect выглядае гэтак жа, як і ў выпадку OAuth. Адзіная розніца ў тым, што ў першасным запыце выкарыстоўваны пэўны scope - openid, - а Кліент у выніку атрымлівае як Доступ да токена, так і ID Token.

Гэтак жа, як і ў струмені OAuth, Доступ да токена у OpenID Connect - гэта нейкае значэнне, не зразумелае КліентСу. З пункту гледжання Кліент'а Доступ да токена прадстаўляе нейкі радок з сімвалаў, які перадаецца разам з кожным запытам да Resource Server'у, а той вызначае, ці сапраўдны токен. ID Token уяўляе сабой зусім іншае.

ID Token - гэта JWT

ID Token — гэта асаблівым чынам адфарматаваны радок сімвалаў, вядомы як JSON Web Token ці JWT (часам токены JWT прамаўляюць як "jots"). Іншым назіральнікам JWT можа здацца незразумелай абракадабрай, аднак Кліент можа атрымаць з JWT розную інфармацыю, такую ​​як ID, імя карыстальніка, час уваходу ва ўліковы запіс, тэрмін заканчэння дзеяння ID Token'а, наяўнасць спроб умяшання ў JWT. Дадзеныя ўнутры ID Token'а называюцца заяўкамі [claims].

У выпадку OIDC таксама маецца стандартны спосаб, з дапамогай якога Кліент можа запытаць дадатковую інфармацыю аб асобе [identity] ад Authorization Server'а, напрыклад, адрас электроннай пошты, выкарыстоўваючы Доступ да токена.

Дадатковыя звесткі пра OAuth і OIDC

Такім чынам, мы сцісла разгледзелі прынцыпы працы OAuth і OIDC. Гатовы капнуць глыбей? Вось дадатковыя рэсурсы, якія дапамогуць даведацца больш пра OAuth 2.0 і OpenID Connect:

• What the Heck is OAuth?
• Nobody Cares About OAuth або OpenID Connect
• Implement the OAuth 2.0 Authorization Code with PKCE Flow
• What is the OAuth 2.0 Grant Type?
• OAuth 2.0 ад Command Line
• Build a Secure Node.js App with SQL Server

Як звычайна, не саромейцеся каментаваць. Каб быць у курсе нашых апошніх навінак, падпісвайцеся на Twitter и YouTube кампаніі Okta для распрацоўшчыкаў!

PS ад перакладчыка

Чытайце таксама ў нашым блогу:

• «Азбука бяспекі ў Kubernetes: аўтэнтыфікацыя, аўтарызацыя, аўдыт»;
• «Карыстальнікі і аўтарызацыя RBAC у Kubernetes»;
• «33+ інструмента для бяспекі Kubernetes»;
• «Бяспека для Docker-кантэйнераў.

Крыніца: habr.com