Прим. прев.: В този страхотен материал на компанията 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 иска да се възползва от името на Собственик на ресурси‘а. - URL адрес за пренасочване:
Линк, по който Сервер за авторизация ще пренасочи Собственик на ресурси‘а след предоставяне на разрешение Client‘у. Понякога я наричат «Връщащ URL» («Callback URL»). - Тип на отговора:
Тип информация, която очаква да получи Client. Най-разпространеният Тип на отговора‘о е код, който Client очаква да получи Код за авторизация. - Обхват:
Това е подробно описание на разрешенията, които се изискват от Client‘у, като достъп до данни или извършване на определени действия. - Съгласие:
Сервер за авторизация взема Обхвати, поисквани от Client‘ом, и пита Собственик на ресурси‘а, готов ли е да предостави Client‘у съответните разрешения. - Client ID:
Този ID се използва за идентификация на Client‘а на Сервер за авторизация‘е. - Клиентска тайна:
Това е парола, известна само на Client‘у и Сервер за авторизация‘у. Тя им позволява да обменят информация поверително. - Код за авторизация:
Временен код с кратък срок на валидност, който Client предоставя Сервер за авторизация‘у в замяна на Токен за достъп. - Токен за достъп:
Ключ, който клиентът ще използва за свързване с Сървър на ресурси‘ом. Това е нещо като бадж или ключ-карта, предоставяща Client‘у разрешения за искане на данни или извършване на действия на Сървър на ресурси‘е от ваше име.
Забележка: понякога Серверът за авторизация и Сървърът на ресурси са един и същ сървър. Въпреки това, в определени случаи те могат да бъдат различни сървъри, дори и да не принадлежат на една и съща организация. Например, Серверът за авторизация може да е услуга на трета страна, на която Сървърът на ресурси има доверие.
Сега, когато се запознахме с основните понятия на OAuth 2.0, нека се върнем към нашия пример и да разгледаме какво се случва в потока на OAuth.
- Вие, Собственик на ресурси, желаете да предоставите на сервиза Terrible Pun of the Day (Client‘у) достъп до вашите контакти, за да може той да изпрати покани на всички ваши приятели.
- Client пренасочва браузъра към страницата на Сервер за авторизация‘а и включва в заявката Client ID, URL адрес за пренасочване, Тип на отговора едно или повече Обхвати (разрешения), от които се нуждае.
- Сервер за авторизация проверява вас, при необходимост, и иска вашето потребителско име и парола.
- Сервер за авторизация представя формуляр Съгласие (за потвърждение) с списък на всички Обхвати, поисквани от Client‘ом. Вие се съгласявате или отказвате.
- Сервер за авторизация пренасочва ви на сайта на Client‘а, използвайки URL адрес за пренасочване вместо Код за авторизация (код на авторизация).
- Client директно се свързва с Сервер за авторизация‘ом (извън браузъра на Собственик на ресурси‘а) и безопасно изпраща Client ID, Клиентска тайна и Код за авторизация.
- Сервер за авторизация проверява данни и отговаря с Токен за достъп‘ом (токен за достъп).
- Сега 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 позволява реализирането на сценарии, при които единственото влизане може да се използва в множество приложения, — този подход също е известен като single sign-on (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 се произнасят като «jots»)За външните наблюдатели, 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
