SAML2 срещу JWT: Разбиране на OpenID Connect, част 2

Тази публикация продължава нашата дискусия за OpenID Connect (OIDC). Разглеждаме един от трите потока за удостоверяване, дефинирани от спецификацията на OIDC - потокът за предоставяне на разрешителния код.

Потоци за удостоверяване на OIDC

Когато OAuth2 дефинира разрешения за разрешение и разширения, спецификацията на OIDC определя потоците за удостоверяване. Концепциите са подобни. Спецификацията определя три потока за удостоверяване; тези потоци се различават от параметрите, които се предават на ОП, съдържанието на отговорите и начина на обработка на отговора. Разграничителят между заявките към крайната точка на оторизацията (и подробностите за потока за удостоверяване) е параметърът return_type. Този параметър има няколко валидни стойности, дефинирани между спецификацията OAuth2 и спецификациите от типа OAuth2 Множество отговори:

Поток на разрешителния код: код

Неявен поток: id_token

Неизразен поток: id_token токен

Хибриден поток: код id_token

Хибриден поток: код на означение

Хибриден поток: код id_token означение

И така, какво означава всичко това? Всеки път, когато видите стойност на „код“ в параметъра response_type, кодът за упълномощаване ще бъде върнат в отговора на крайната точка на оторизацията. Всеки път, когато „id_token“ е включен в параметъра response_type, id_token ще бъде включен в отговора. Всеки път, когато „параметърът“ е включен в параметъра response_type, access_token ще бъде включен в отговора от крайната точка на оторизацията. Тези подробности влияят върху структурата на отговора, какви стъпки за обработка предприема следващата страна (RP, клиент) и какви случаи на използване могат да бъдат разгледани, както ще видите по-долу. Забележка,

  • Потокът на кодове за разрешение на OIDC директно разширява предоставянето на код за разрешение на OAuth2. OIDC имплицитният поток и OIDC хибридният поток разширяват потока на код за разрешение на OIDC.
  • Кодът на авторизационния код response_type на код, дефиниран от OIDC, е различен от типа на име на отговор със същото име, определен от спецификацията OAuth2.

Всички примерни заявки и отговори, използвани в тази публикация, са вариации на примерите, дадени в спецификацията на OIDC.

Поток на авторизационен код (спецификация на OIDC v1.0, раздел 3.1): Това е OIDC версия на кода за разрешение на OAuth2. Този поток има отговор_тип, зададен на „код“. Примерът, представен тук, използва цялата функционалност, налична в Грантът на разрешителния код за изпълнение:

  • Удостоверяване на крайния потребител
  • Удостоверяване на отпускаща страна (клиент, приложение), по избор.
  • Relaying Party (RP) не вижда идентификационни данни (парола) на крайния потребител
  • Потребителският агент не вижда токена за достъп или идентификатора
  • SSO до RP
  • Получете множество токени за достъп или многократен достъп.
  • Извършете API (Resource) повикване до доставчика на API (Resource Server) с Access Token.
Поток на авторизационен код с SSO & API Call (response_type = code)

Стъпките в диаграмата по-горе се преминават през следващата. Крайният потребител инициира процеса на влизане в приложението, като въвежда адреса на уебсайта в уеб браузър или подобно действие - не е показано на диаграмата. След това браузърът (User Agent) изпраща заявка до RP, която пресича заявката и вижда, че тя не е част от автентифицирана сесия - също не е показана на диаграмата (спецификацията не покрива тази част).

Искането за удостоверяване

RP пренасочва потребителския агент към доставчика на OpenID (OP) - стъпка (A). Получената заявка изглежда като:

GET / oidc / разрешаване?
 response_type = код
 И обхват = OpenID% 20profile% 20email
 & Client_id = s6BhdRkqt3
 & Състояние = af0ifjsldkj
 & redirect_uri = https% 3A% 2F% 2Fclient.example.org% 2Fcb HTTP / 1.1
 Водещ: server.example.com

ОП ще пренасочи потребителския агент към работен поток за вход, който се обслужва от ОП - стъпка (B). Подробностите за това как работи автентификацията са извън обхвата на спецификацията на OIDC. Ние нарекохме OIDC протокол за удостоверяване, но той не определя детайлите за това, как потребителят е удостоверен. Това не е по-различно от това как работи SAML2 Web Browser SSO Profile - реалната автентификация на потребителя може да бъде голямо разнообразие от механизми, които зависят от възможностите на доставчика на идентичност (OP). Работният процес за удостоверяване може също да съдържа проверка, която да позволи на крайния потребител да даде съгласие на RP за ресурси, собственост на крайния потребител (делегиран достъп, предоставен на RP в ресурса).

Успешен отговор за удостоверяване

След успешно удостоверяване, ОП ще пренасочи потребителя обратно към крайната точка на оторизацията с набор от информация за проследяване на сесията (вероятно под формата на бисквитка на сесия, зависи от внедряването). Крайната точка на упълномощаването ще върне HTTP пренасочване (с код на упълномощаване) към URL адреса на RP, който изглежда нещо подобно на следното - стъпка (C):

HTTP / 1.1 302 намерено
 Местоположение: https://client.example.org/cb?
 код = SplxlOBeZQQYbYS6WxSbIA
 & Състояние = af0ifjsldkj

В резултат на това потребителският агент изпраща следното искане към RP:

ПОЛУЧИТЕ https://client.example.org/cb?
 код = SplxlOBeZQQYbYS6WxSbIA
 & Състояние = af0ifjsldkj

Грешка при удостоверяването

Ако възникне грешка по време на фазата на удостоверяване и съгласие (или нещо друго, което води до връщането на кода на авторизацията), Крайната точка на разрешение ще върне грешка, подобна на следното:

HTTP / 1.1 302 намерено
  Местоположение: https://client.example.org/cb?
    грешка = invalid_request
    & ERROR_DESCRIPTION =
      Не се поддържа% 20response_type% 20value
    & Състояние = af0ifjsldkj

Заявка за жетони

На този етап RP е получил кода за разрешение, без изобщо да е виждал паролата на крайния потребител (или други идентификационни данни). Сега RP трябва да получи Token Access, ID Token и друга информация от крайната точка на маркера. И така, RP изпраща нещо като следната заявка към крайната точка на маркера - стъпка (D):

POST / oidc / token HTTP / 1.1
 Водещ: server.example.com
 Тип съдържание: приложение / x-www-form-urlencoded
 grant_type = authorization_code &
 код = SplxlOBeZQQYbYS6WxSbIA &
 redirect_uri = HTTPS% 3A% 2F% 2Fclient.example.org% 2Fcb &
 client_id = s6BhdRkqt3 &
 client_secret = blah_blah_blah_1234

Параметър client_secret трябва да присъства само ако RP е поверителен клиент (точно както при общия код за разрешаване на OAuth2). Съществуват алтернативни методи за удостоверяване на RP до крайната точка на Token, описани в раздел 9 от спецификацията OIDC; спецификацията OAuth2 също поддържа Basic Authentication (това е предпочитаният метод).

Отговор на токена

Отговорът от крайната точка на маркера за потока на код за оторизация изглежда като подобен начин - стъпка (E).

HTTP / 1.1 200 OK
 Тип съдържание: application / json
 Кеш контрол: няма магазин
 Прагма: без кеш
 {
 „Access_token“: „SlAV32hkKG“,
 „Token_type“: „Приносител“,
 „Refresh_token“: „8xLOxBtZp8“,
 „Срок на изтичане_в“: 3600,
 „Id_token“: „eyJhbGciOiJSUzI1NiIsImtpZCI6IjFlOWdkazcifQ.ewogImlzc
 yI6ICJodHRwOi8vc2VydmVyLmV4YW1wbGUuY29tIiwKICJzdWIiOiAiMjQ4Mjg5
 NzYxMDAxIiwKICJhdWQiOiAiczZCaGRSa3F0MyIsCiAibm9uY2UiOiAibi0wUzZ
 fV3pBMk1qIiwKICJleHAiOiAxMzExMjgxOTcwLAogImlhdCI6IDEzMTEyODA5Nz
 AKfQ.ggW8hZ1EuVLuxNuuIJKX_V8a_OMXzR0EHR9R6jgdqrOOF4daGU96Sr_P6q
 Jp6IcmD3HP99Obi1PRs-cwh3LO-p146waJ8IhehcwL7F09JdijmBqkvPeB2T9CJ
 NqeGpe-gccMg4vfKjkM8FcGvnzZUN4_KSP0aAp1tOJ1zZwgjxqGByKHiOtX7Tpd
 QyHE5lcMiKPXfEIQILVq0pc_E2DzL7emopWoaoZTF_m0_N0YzFC6g6EJbOEoRoS
 K5hoDalrcvRYLSrQAZZKflyuVCyixEoV9GfNQC3_osjzw2PAithfubEEBLuVVk4
 XUVrWOLrLl0nx7RkKU8NXNHq-rvKMzqg "
 }

Валидиране на токени

Сега токенът за ID (свойството id_token по-горе) трябва да бъде валидиран в раздел 3.1.3.7 от спецификацията OIDC - стъпка (F) - не пропускайте тази част, това компрометира сигурността. За този поток на удостоверяване идентификаторът ще съдържа свойство at_hash (хеш за достъп на токен), което може да се използва за валидиране на токена за достъп; това не е задължително, но се препоръчва - стъпка (G).

В сценариите на OIDC ID токенът се използва за стъпките за удостоверяване на RP, а токенът за достъп се използва за

  • по желание извлечете информация от крайната точка на UserInfo
  • провеждайте обаждания към ресурсния сървър (доставчик на API в нашия пример)

Това е много различно от това как работи OAuth2.

Достъп до токен обхват

Сега, ако токенът за достъп има концепция за аудитория (може да не е случаят с непрозрачните маркери), тогава е възможно (вероятно вероятно, в зависимост от сценария), RP да са необходими уникални токени за достъп за достъп до крайната точка на UserInfo и достъп до ресурс сървър. Ако случаят е такъв, тогава може да се извърши второ повикване до крайната точка на токена със същия код на разрешение, изискващ втори маркер за достъп с аудиторията на ресурсния сървър - при условие, че ОП е конфигуриран да позволява такъв достъп. Друг потенциален подход би бил използването на обхват на токена за достъп, който поддържа множество аудитории - JWT позволява това - но, вашата ОП трябва да го поддържа и има потенциални проблеми със сигурността, тъй като броят на участниците, които могат да правят интересни неща с вашите жетони за самоличност, се увеличава ( по този начин, увеличаване на риска).

На следващо място, ако RP се нуждае от допълнителни претенции, той може да се свърже с крайната точка на UserInfo на ОП, за да ги получи, както е описано по-горе - стъпки (H) и (I). Интересно е да се отбележи, че RP има ID токен и той може да съдържа всяка претенция, която би могла да бъде върната от UserInfo Endpoint. Но доставчиците на ОП са склонни да поставят някои ограничения върху гъвкавостта на тази функция.

Обадете се към ресурсния сървър

На следващо място, RP може да получи достъп до ресурса на сървъра за ресурси (нека го наречем API на доставчик на API), като направи повикване към API с маркера за достъп в заглавието за упълномощаване, както разгледахме преди - стъпка (J). В публикацията за разбиране на OAuth2 беше прието, че маркерът за достъп е JWT означение; спецификацията JWT определя как да валидира токена за достъп на сървъра за ресурси (API доставчик). Ако токенът за достъп е непрозрачен маркер, тогава ресурсният сървър трябва да комуникира с ОП, използвайки механизми, определени извън спецификацията (и вероятно зависи от внедряването). През октомври 2015 г. беше публикувана интроспекция на OAuth 2.0 Token Introspection (RFC 7662), която „определя метод за защитен ресурс за запитване
 сървър за разрешаване на OAuth 2.0 за определяне на активното състояние на
 Маркер OAuth 2.0 и за определяне на метаинформация за този маркер. “По принцип тя определя крайната точка на сървъра за оторизация, която може да валидира маркер и да извлече информация за него (крайна точка на интроспекция на Token). Има известно припокриване между крайната точка на OIDC UserInfo и тази нова крайна точка, но интроспекционната крайна точка на OAuth2 Token осигурява възможността за валидиране на непрозрачен маркер за достъп (въпреки че това не е основната му цел). Въпреки това маркерът за достъп е валидиран, тази стъпка трябва да се извърши, преди обработката на заявките да продължи на сървъра на ресурсите (API доставчик) - стъпка (K).

И накрая, ресурсният сървър може да предаде получения токен за достъп до крайната точка на UserInfo, за да получи токен на ID със съответните (и разрешени) претенции за крайния потребител - стъпки (L) и (M). Обработката на заявката за API може да продължи и отговор може да бъде върнат на RP (действайки като потребител на API в този сценарий).

Същият сценарий, по който току-що преминахме, е описан в диаграмата на последователностите по-долу.

резюме

С това завършваме прегледът на кода за разрешение на OIDC, предоставящ поток за удостоверяване.

В следващата публикация изследваме последните два потока за удостоверяване: имплицитният поток и хибридният поток.

Моля, оставете въпроси или коментари по-долу.