Прим. прев.: В този страхотен материал на компанията Okta ясно и накратко се обяснява как работят OAuth и OIDC (OpenID Connect). Тези знания ще бъдат полезни за разработчици, системни администратори и дори „обикновени потребители“ на популярни уеб приложения, които вероятно също обменят конфиденциални данни с други услуги.
В „каменната епоха“ на интернет, споделянето на информация между услугите беше лесно. Просто давахте своя логин и парола от една услуга на друга, за да се влезе в профила ви и да се получи необходимата информация.
„Предоставете банкова сметка“. — „Обещаваме, че с паролата и парите всичко ще бъде наред. Наистина честно!“ *хи-хи*
Ужас! Никой и никога не трябва да иска от потребителя да сподели логин и парола, неговите данни за вход, с друга услуга. Няма никаква гаранция, че организацията зад тази услуга ще съхранява данните в безопасност и няма да събира повече лична информация, отколкото е необходимо. Може да изглежда налудничаво, но някои приложения все още прилагат подобна практика!
Днес съществува единен стандарт, който позволява на една услуга безопасно да използва данните на друга. За съжаление, подобни стандарти използват много жаргон и термини, което усложнява разбирането им. Целта на този материал е чрез простички илюстрации да обясни как работят те (Мислите, че рисунките ми приличат на детска измама? Добре, няма проблем!).
Между другото, това ръководство също е налично под форма на видео:
Дами и господа, запознайте се с: OAuth 2.0
— това е стандарт за сигурност, който позволява на едно приложение да получи разрешение за достъп до информация в друго приложение. Последователността на действията за издаване на разрешение [permission] (или съгласие [consent]) често се нарича авторизация [authorization] или дори делегирована авторизация [delegated authorization]. С помощта на този стандарт вие позволявате на приложението да чете данни или да използва функции на друго приложение от ваше име, без да споделяте паролата си. Страхотно!
Като пример представете си, че сте открили сайт с името „Неудобна каламбур на деня“ [Terrible Pun of the Day] и решихте да се регистрирате на него, за да получавате ежедневни каламбури под формата на текстови съобщения на телефона. Сайтът ви хареса много и решихте да го споделите с всички свои познати. В крайна сметка, страшните каламбури харесват на всички, нали?
«Неуспешен каламбур на деня: Чули ли сте за момчето, което загуби лявата половина на тялото си? Сега той винаги е десен!» (преводът е приблизителен, тъй като в оригинала има собствена игра на думи — бел. прев.)
Разбира се, че не е опция да пишете на всеки човек от списъка с контакти. И ако поне малко приличате на мен, ще направите всичко възможно, за да избегнете ненужната работа. За щастие, Terrible Pun of the Day може сам да покани всички ваши приятели! Единственото, което трябва да направите, е да му предоставите достъп до имейл адресите на контактите — сайтът сам ще им изпрати покани (OAuth управлява)!
«Всички обичат каламбури! — Вече сте влезли? — Искате ли да дадете достъп на сайта Terrible Pun of the Day до списъка с контакти? — Благодаря! Сега всеки ден ще изпращаме напомняния на всички, които познавате, до края на вековете! Вие сте най-добрият приятел!»
- Изберете своя имейл услуга.
- При необходимост отидете на сайта на имейла и влезте в профила си.
- Дайте разрешение на сайта Terrible Pun of the Day да получи достъп до контактите.
- Върнете се на сайта 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, нека поговорим за значението на някои термини:
- Собственик на ресурси:
Това сте вие! Вие притежавате своите идентификационни данни, своите данни и управлявате всички действия, които могат да бъдат извършени с вашите акаунти. - Client:
Приложение (например, услугата Terrible Pun of the Day), което иска да получи достъп или да извърши определени действия от името Собственик на ресурси‘а. - Сървър за удостоверяване:
Приложение, което знае Собственик на ресурси‘а и в което има Собственик на ресурси‘а вече регистриран акаунт. - Сървър за ресурси:
Приложен интерфейс (API) или услуга, чрез Client която иска да се възползва от името на Собственик на ресурси‘а. - URI за пренасочване:
Линкът, по който Сървър за удостоверяване ще пренасочи Собственик на ресурси‘а след предоставяне на разрешение Client‘у. Понякога се нарича "Връщащ URL" ("Callback URL"). - Тип на отговора:
Вид информация, която очаква да получи Client. Най-разпространеният Тип на отговора‘ом е кодът, т.е. Client предполага да получи Код за удостоверяване. - Обхват:
Това е подробно описание на разрешенията, които са необходими Client‘у, като достъп до данни или извършване на определени действия. - Съгласие:
Сървър за удостоверяване взима Обхвати, изисквани Client‘ом, и пита Собственик на ресурси‘а, готов ли е да предостави Client‘у съответните разрешения. - Client secret:
Този ID се използва за идентифициране на Client‘а на Сървър за удостоверяване‘е. - Тайна на клиента:
Това е парола, известна само на Client‘у и Сървър за удостоверяване‘у. Тя им позволява да обменят информация конфиденциално. - Код за удостоверяване:
Временен код с малък период на действие, който Client предлага Сървър за удостоверяване‘у срещу Токен за достъп. - Токен за достъп:
Ключ, който клиентът ще използва за свързване с Сървър за ресурси‘ом. Това е като значка или ключ-карта, предоставяща Client‘у разрешение да иска данни или да извършва действия на Сървър за ресурси‘е от ваше име.
Забележка: понякога сървърът за удостоверяване и сървърът за ресурси са един и същ сървър. Въпреки това, в някои случаи те могат да бъдат различни сървъри, дори да не принадлежат на една и съща организация. Например, сървърът за удостоверяване може да бъде външна услуга, на която доверява сървърът за ресурси.
Сега, когато сме се запознали с основните концепции на OAuth 2.0, нека се върнем на нашия пример и подробно да разгледаме какво се случва в потока на OAuth.
- Вие, Собственик на ресурси, желаете да предоставите на услугата Terrible Pun of the Day (Client‘у) достъп до вашите контакти, за да може тя да изпрати покани на всички ваши приятели.
- Client пренасочва браузъра към страницата на Сървър за удостоверяване‘а и включва в заявката Client secret, URI за пренасочване, Тип на отговора и едно или повече Обхвати (разрешения), от които има нужда.
- Сървър за удостоверяване проверява вас, изисквайки при необходимост логин и парола.
- Сървър за удостоверяване извежда форма Съгласие (за потвърждение) с изброяване на всички Обхвати, изисквани от Client‘ом. Вие се съгласявате или отказвате.
- Сървър за удостоверяване пренасочва ви обратно на сайта на Client‘а, използвайки URI за пренасочване вместо с Код за удостоверяване (код за удостоверяване).
- Client в директна връзка с Сървър за удостоверяване‘ом (в обход на браузъра на Собственик на ресурси‘а) и сигурно изпраща Client secret, Тайна на клиента и Код за удостоверяване.
- Сървър за удостоверяване проверява данните и отговаря с Токен за достъп‘ом (токен за достъп).
- Сега Client може да се използва Токен за достъп за изпращане на заявка за Сървър за ресурси с цел получаване на списък с контакти.
Client ID и Secret
Дълго преди да позволите на Terrible Pun of the Day да получи достъп до контактите, Client и Authorization Server установили работни отношения. Authorization Server генерирал Client ID и Client Secret (понякога наричани App ID и App Secret) и ги изпрати на Client’а за по-нататъшно взаимодействие в рамките на OAuth.
«— Здравей! Искам да работя с теб! — Няма проблем! Ето ти твоите Client ID и Secret!»
Името намеква, че Client Secret трябва да остане в тайна, така че само Client и Authorization Server да го знаят. Защото именно с него Authorization Server потвърд радостта на Client’а.
Но това не е всичко… Моля, приветствайте OpenID Connect!
OAuth 2.0 е разработен специално за авторизация — за предоставяне на достъп до данни и функции от едно приложение на друго. (OIDC) е тънък слой върху OAuth 2.0, добавящ информация за вписването и профила на потребителя, който е влязъл в системата. Организацията на сесията за вписване често се нарича автентикация [authentication], а информацията за потребителя, който е влязъл в системата (т.е. за Собственик на ресурси‘е), — лични данни [identity]. Ако Authorization Server поддържа OIDC, понякога го наричат доставчик на лични данни [identity provider], тъй като той предоставя Client‘у информация за Собственик на ресурси‘е.
OpenID Connect позволява реализирането на сценарии, при които единният вход може да се използва в множество приложения, — този подход е известен като единичен вход (SSO). Например, приложението може да поддържа SSO интеграция със социални мрежи, като Facebook или Twitter, позволявайки на потребителите да използват профила, който вече имат и който предпочитат.
Процесът (flow) на OpenID Connect изглежда по подобен начин, както при OAuth. Единствената разлика е, че в първоначалната заявка използваният конкретен scope е openid, — а Client в крайна сметка получава като Токен за достъп, така и ID Token..
Както и при потока на OAuth, Токен за достъп в OpenID Connect — това е стойност, непозната за Client‘у. От гледна точка на Client‘а Токен за достъп представлява набор от символи, който се предава с всяка заявка към Сървър за ресурси‘у, а той определя дали токенът е валиден. ID Token. представлява нещо съвсем различно.
ID Token — това е JWT
ID Token. — това е специално форматиран набор от символи, известен като JSON Web Token или JWT (понякога токените JWT се произнасят като «джацс»). За външните наблюдатели JWT може да изглежда като неразбираема абракадабра, обаче Client може да извлече различна информация от JWT, като ID, потребителско име, време на влизане в профила, срок на действие ID Token.и опити за намеса в JWT. Данните вътре ID Token.се наричат заявки [claims].
В случая с OIDC съществува стандартен начин, по който Client може да поиска допълнителна информация за самоличността [identity] от Сървър за удостоверяване, например, имейл адрес, използвайки Токен за достъп.
Допълнителна информация за OAuth и OIDC
И така, накратко разгледахме принципите на работа на OAuth и OIDC. Готови ли сте да задълбочите? Ето и допълнителни ресурси, които ще помогнат да научите повече за OAuth 2.0 и OpenID Connect:
Както обикновено, не се колебайте да оставите коментари. За да бъдете в крак с нашите най-нови предложения, се абонирайте за и компанията Okta за разработчици!
P.S. от преводача
Прочетете също в нашия блог:
- «»;
- «»;
- «»;
- «».
Източник: habr.com
