Забележка. превод: Тази страхотна статия от Okta обяснява как работят OAuth и OIDC (OpenID Connect) по прост и ясен начин. Това знание ще бъде полезно за разработчиците, системните администратори и дори „обикновените потребители“ на популярни уеб приложения, които най-вероятно също обменят поверителни данни с други услуги.
В каменната ера на интернет споделянето на информация между услугите беше лесно. Вие просто дадохте вашето потребителско име и парола от една услуга на друга, така че той да влезе във вашия акаунт и да получи всякаква необходима информация.
— Дай ми банковата си сметка. „Обещаваме, че всичко ще бъде наред с паролата и парите. Това е честно, честно!" *хи-хи*
Ужас! Никой никога не трябва да изисква потребител да споделя потребителско име и парола, акредитивни писма, с друга услуга. Няма гаранция, че организацията зад тази услуга ще пази данните защитени и няма да събира повече лична информация от необходимото. Може да звучи налудничаво, но някои приложения все още използват тази практика!
Днес има единен стандарт, който позволява на една услуга да използва безопасно данните на друга. За съжаление такива стандарти използват много жаргон и термини, което усложнява тяхното разбиране. Целта на този материал е да обясни как работят с помощта на прости илюстрации (Мислите ли, че моите рисунки приличат на детски мазки? О, добре!).
Между другото, това ръководство е достъпно и във видео формат:
Дами и господа, добре дошли: OAuth 2.0
е стандарт за сигурност, който позволява на едно приложение да получи разрешение за достъп до информация в друго приложение. Последователност от стъпки за издаване на разрешение [разрешение] (Or съгласие [съгласие]) често се обаждат разрешение [упълномощаване] или делегирана оторизация [делегирано упълномощаване]. С този стандарт вие позволявате на приложение да чете данни или да използва функциите на друго приложение от ваше име, без да му давате вашата парола. клас!
Като пример, да приемем, че откриете сайт, наречен „Нещастна каламбур на деня“ [Ужасна игра на думи на деня] и реши да се регистрира в него, за да получава ежедневни каламбури под формата на текстови съобщения на телефона. Много сте харесали сайта и сте решили да го споделите с всичките си приятели. В края на краищата всеки харесва зловещите каламбури, нали?
„Нещастна игра на думи на деня: чухте ли за човека, който загуби лявата половина на тялото си? Сега той винаги е прав!“ (приблизителен превод, защото оригиналът има собствен каламбур - прибл. прев.)
Ясно е, че писането на всеки човек от списъка с контакти не е опция. И ако сте дори малко като мен, тогава ще отидете на всичко, за да избегнете ненужна работа. За щастие, Terrible Pun of the Day може сам да покани всичките ви приятели! За да направите това, просто трябва да отворите достъп до имейла на вашите контакти - самият сайт ще им изпрати покани (OAuth правила)!
„Всички обичат каламбури! - Вече сте влезли? „Искате ли да разрешите на уебсайта Terrible Pun of the Day достъп до вашия списък с контакти? - Благодаря ти! Отсега нататък ще изпращаме напомняния всеки ден на всички, които познавате, до края на времето! Ти си най-добрият приятел!"
- Изберете вашата имейл услуга.
- Ако е необходимо, отидете на сайта за поща и влезте в акаунта си.
- Дайте разрешение на Terrible Pun of the Day за достъп до вашите контакти.
- Върнете се към сайта Ужасна каламбур на деня.
В случай, че промените решението си, приложенията, използващи OAuth, също предоставят начин за отмяна на достъпа. След като решите, че вече не желаете да споделяте контакти с Terrible Pun of the Day, можете да отидете на сайта за поща и да премахнете сайта за игра на думи от списъка с разрешени приложения.
OAuth поток
Току-що минахме през това, което обикновено се нарича поток [поток] OAuth. В нашия пример този поток се състои от видими стъпки, както и няколко невидими стъпки, в които две услуги се договарят за защитен обмен на информация. Предишният пример за ужасна каламбур на деня използва най-често срещания поток на OAuth 2.0, известен като поток „код за оторизация“. [поток на "код за упълномощаване"].
Преди да се потопим в подробностите за това как работи OAuth, нека поговорим за значението на някои термини:
- Собственик на ресурс:
Това си ти! Вие притежавате вашите идентификационни данни, вашите данни и контролирате всички дейности, които могат да бъдат извършени с вашите акаунти. - Удовлетвореност:
Приложение (например услугата Terrible Pun of the Day), което иска достъп до или извършване на определени действия от името на Собственик на ресурс'а. - Сървър за оторизация:
Приложението, което знае Собственик на ресурс'a и в който u Собственик на ресурс'а вече имам акаунт. - сървър за ресурси:
Интерфейс за програмиране на приложения (API) или услуга, която Удовлетвореност иска да използва от името Собственик на ресурс'а. - URI за пренасочване:
Връзката, която Сървър за оторизация ще пренасочи Собственик на ресурс'и след даване на разрешение Удовлетвореност'в. Понякога се нарича "URL адрес за обратно извикване". - тип отговор:
Типът информация, която се очаква да бъде получена Удовлетвореност. Най-често тип отговор'ohm е кодът, т.е Удовлетвореност очаква да получи Код за разрешение. - Обхват:
Това е подробно описание на необходимите разрешения Удовлетвореност'y, като достъп до данни или извършване на определени действия. - Съгласие:
Сървър за оторизация барета Scopesпоискано Удовлетвореност'ом, и пита Собственик на ресурс'a, готов ли е да предостави Удовлетвореност'имат съответните разрешения. - Клиентски идентификационен номер:
Този идентификатор се използва за идентифициране Удовлетвореност'a на Сървър за оторизация'е. - Клиентска тайна:
Това е паролата, която се знае само Удовлетвореност'и и Сървър за оторизация'в. Това им позволява да споделят информация насаме. - Код за разрешение:
Временен код с кратък срок на валидност, който Удовлетвореност Той осигурява Сървър за оторизация'y в замяна на Token Access. - Token Access:
Ключът, с който клиентът ще комуникира сървър за ресурси'ом. Нещо като значка или ключова карта, която предоставя Удовлетвореност„имат разрешение да изискват данни или да извършват действия върху сървър за ресурсиот ваше име.
Внимание: Понякога сървърът за оторизация и сървърът за ресурси са един и същ сървър. В някои случаи обаче това може да са различни сървъри, дори и да не принадлежат към една и съща организация. Например сървърът за оторизация може да е услуга на трета страна, на която сървърът за ресурси има доверие.
Сега, след като разгледахме основните концепции на OAuth 2.0, нека се върнем към нашия пример и да разгледаме по-отблизо какво се случва в OAuth потока.
- Вие, Собственик на ресурс, искате да предоставите услугата Ужасна каламбур на деня (Удовлетвореностy) достъп до вашите контакти, така че да могат да изпращат покани до всички ваши приятели.
- Удовлетвореност пренасочва браузъра към страницата Сървър за оторизация'a и включете в заявката Клиентски идентификационен номер, URI за пренасочване, тип отговор и един или повече Scopes (разрешения), от които има нужда.
- Сървър за оторизация проверява ви, като изисква потребителско име и парола, ако е необходимо.
- Сървър за оторизация показва формуляр Съгласие (потвърждения) със списък на всички Scopesпоискано Удовлетвореност'ом. Вие се съгласявате или отказвате.
- Сървър за оторизация ви пренасочва към сайта Удовлетвореност'a, използвайки URI за пренасочване заедно с Код за разрешение (код за оторизация).
- Удовлетвореност комуникира директно с Сървър за оторизация'ohm (заобикаляйки браузъра Собственик на ресурс'a) и безопасно изпраща Клиентски идентификационен номер, Клиентска тайна и Код за разрешение.
- Сървър за оторизация проверява данните и отговаря с Token Access'om (токен за достъп).
- Сега Удовлетвореност може да използва Token Access да изпратите заявка до сървър за ресурси за да получите списък с контакти.
Клиентски идентификатор и тайна
Много преди да позволите на Terrible Pun of the Day достъп до вашите контакти, клиентът и сървърът за оторизация са установили работещи отношения. Сървърът за оторизация генерира ИД на клиента и тайната на клиента (понякога наричани ID на приложението и Тайна на приложението) и ги изпрати на клиента за по-нататъшно взаимодействие в рамките на OAuth.
"- Здравейте! Бих искал да работя с вас! - Разбира се, не е проблем! Ето вашето клиентско име и тайна!”
Името предполага, че тайната на клиента трябва да се пази в тайна, така че само клиентът и сървърът за оторизация да я знаят. В крайна сметка именно с негова помощ сървърът за оторизация потвърждава истинността на клиента.
Но това не е всичко... Моля, приветствайте OpenID Connect!
OAuth 2.0 е предназначен само за оторизация - за предоставяне на достъп до данни и функции от едно приложение към друго. (OIDC) е тънък слой върху OAuth 2.0, който добавя данни за вход и профил на потребителя, който е влязъл в акаунта. Организацията на сесия за влизане често се нарича удостоверяване [удостоверяване]и информация за потребителя, влязъл в системата (т.е. относно Собственик на ресурсд), — лични данни [самоличност]. Ако сървърът за оторизация поддържа OIDC, понякога се нарича доставчик на лични данни [доставчик на самоличност]защото осигурява Удовлетвореност„имам информация за Собственик на ресурс'е.
OpenID Connect ви позволява да реализирате сценарии, при които едно влизане може да се използва в множество приложения - този подход е известен също като единично влизане (SSO). Например, дадено приложение може да поддържа SSO интеграция със социални мрежи като Facebook или Twitter, което позволява на потребителите да използват акаунт, който вече имат и предпочитат да използват.
Потокът (поток) OpenID Connect изглежда по същия начин, както в случай на OAuth. Единствената разлика е, че в първичната заявка конкретният използван обхват е openid, - А Удовлетвореност в крайна сметка става като Token AccessИ ID Токен.
Точно както в потока OAuth, Token Access в OpenID Connect това е някаква стойност, която не е ясна Удовлетвореност'в. От гледна точка Удовлетвореност'а Token Access представлява низ от знаци, който се предава заедно с всяка заявка към сървър за ресурси'y, което определя дали токенът е валиден. ID Токен представлява съвсем различно нещо.
ID Token е JWT
ID Токен е специално форматиран низ от знаци, известен като JSON Web Token или JWT (понякога JWT токените се произнасят като "jots"). За външни наблюдатели JWT може да изглежда като неразбираема глупост, но Удовлетвореност може да извлича различна информация от JWT, като ID, потребителско име, време за влизане, дата на изтичане ID Токен'a, наличието на опити за намеса в JWT. Данни вътре ID Токен'a се наричат приложения [искове].
В случая на OIDC има и стандартен начин, по който Удовлетвореност може да поиска допълнителна информация за лицето [самоличност] от Сървър за оторизация'a, например, имейл адрес, използващ Token Access.
Научете повече за OAuth и OIDC
И така, прегледахме накратко как работят OAuth и OIDC. Готови ли сте да копаете по-дълбоко? Ето допълнителни ресурси, които да ви помогнат да научите повече за OAuth 2.0 и OpenID Connect:
Както винаги, не се колебайте да коментирате. За да сте в крак с последните ни новини, абонирайте се за и Okta за разработчици!
PS от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «".
Източник: www.habr.com