Redirect URI (reply URL) restrictions and limitations
A redirect URI, or reply URL, is the location where the authorization server sends the user once the app has been successfully authorized and granted an authorization code or access token. The authorization server sends the code or token to the redirect URI, so it’s important you register the correct location as part of the app registration process.
The Azure Active Directory (Azure AD) application model specifies these restrictions to redirect URIs:
Redirect URIs that contain a path segment are not appended with a trailing slash in the response.
Maximum number of redirect URIs
This table shows the maximum number of redirect URIs you can add to an app registration in the Microsoft identity platform.
| Accounts being signed in | Maximum number of redirect URIs | Description |
|---|---|---|
| Microsoft work or school accounts in any organization’s Azure Active Directory (Azure AD) tenant | 256 | signInAudience field in the application manifest is set to either AzureADMyOrg or AzureADMultipleOrgs |
| Personal Microsoft accounts and work and school accounts | 100 | signInAudience field in the application manifest is set to AzureADandPersonalMicrosoftAccount |
Maximum URI length
You can use a maximum of 256 characters for each redirect URI you add to an app registration.
Redirect URIs in application vs. service principal objects
Supported schemes
HTTPS: The HTTPS scheme ( https:// ) is supported for all HTTP-based redirect URIs.
HTTP: The HTTP scheme ( http:// ) is supported only for localhost URIs and should be used only during active local application development and testing.
| Example redirect URI | Validity |
|---|---|
| https://contoso.com | Valid |
| https://contoso.com/abc/response-oidc | Valid |
| https://localhost | Valid |
| http://contoso.com/abc/response-oidc | Invalid |
| http://localhost | Valid |
| http://localhost/abc | Valid |
Localhost exceptions
Per RFC 8252 sections 8.3 and 7.3, «loopback» or «localhost» redirect URIs come with two special considerations:
From a development standpoint, this means a few things:
This is especially important when you want to use different authentication flows in the same application registration, for example both the authorization code grant and implicit flow. To associate the correct response behavior with each redirect URI, the login server must be able to distinguish between the redirect URIs and cannot do so when only the port differs.
The IPv6 loopback address ( [::1] ) is not currently supported.
Prefer 127.0.0.1 over localhost
You cannot, however, use the Redirect URIs text box in the Azure portal to add a loopback-based redirect URI that uses the http scheme:
To add a redirect URI that uses the http scheme with the 127.0.0.1 loopback address, you must currently modify the replyUrlsWithType attribute in the application manifest.
Restrictions on wildcards in redirect URIs
Wildcard URIs like https://*.contoso.com may seem convenient, but should be avoided due to security implications. According to the OAuth 2.0 specification (section 3.1.2 of RFC 6749), a redirection endpoint URI must be an absolute URI.
Wildcard URIs are currently unsupported in app registrations configured to sign in personal Microsoft accounts and work or school accounts. Wildcard URIs are allowed, however, for apps that are configured to sign in only work or school accounts in an organization’s Azure AD tenant.
To add redirect URIs with wildcards to app registrations that sign in work or school accounts, use the application manifest editor in App registrations in the Azure portal. Though it’s possible to set a redirect URI with a wildcard by using the manifest editor, we strongly recommend you adhere to section 3.1.2 of RFC 6749. and use only absolute URIs.
If your scenario requires more redirect URIs than the maximum limit allowed, consider the following state parameter approach instead of adding a wildcard redirect URI.
Use a state parameter
If you have several subdomains and your scenario requires that, upon successful authentication, you redirect users to the same page from which they started, using a state parameter might be helpful.
This approach allows a compromised client to modify the additional parameters sent in the state parameter, thereby redirecting the user to a different URL, which is the open redirector threat described in RFC 6819. Therefore, the client must protect these parameters by encrypting the state or verifying it by some other means, like validating the domain name in the redirect URI against the token.
Next steps
Learn about the app registration Application manifest.
Ограничения для URI перенаправления (URL-адресов ответа)
URI перенаправления, или URL-адрес ответа, — это расположение, в которое сервер авторизации будет отправлять пользователя после успешной авторизации приложения и которому был предоставлен код авторизации или маркер доступа. Сервер авторизации отправляет на URI перенаправления код или маркер ответа, поэтому в процессе регистрации приложения важно зарегистрировать правильный адрес.
Модель приложения Azure Active Directory (Azure AD) определяет следующие ограничения для URI перенаправления:
К URI перенаправления, содержащих сегмент пути, не добавляется замыкающая косая черта в ответе.
Максимальное число URI перенаправления
В этой таблице указано максимальное число URI перенаправления, которые можно добавить для зарегистрированного приложения на платформе удостоверений Майкрософт.
| Учетные записи для входа | Максимальное число URI перенаправления | Описание |
|---|---|---|
| Рабочие или учебные учетные записи Майкрософт в клиенте Azure Active Directory (Azure AD) любой организации | 256 | Для поля signInAudience в манифесте приложения установлено signInAudience или AzureADMultipleOrgs |
| Личные учетные записи Майкрософт и рабочие и учебные учетные записи | 100 | Для поля signInAudience в манифесте приложения установлено signInAudience |
Максимальная длина URI
Длина каждого URI перенаправления, добавляемого для зарегистрированного приложения, должна составлять не более 256 символов.
Перенаправление URI в главных объектах приложений и субъектов-служб
Поддерживаемые схемы
HTTPS: схема HTTPS ( ) поддерживается для всех URI перенаправления на базе протокола HTTP.
HTTP: схема HTTP ( ) поддерживается только для URI перенаправления localhost и используется исключительно на этапах локальной разработки и тестирования приложения.
| Пример URI перенаправления | Срок действия |
|---|---|
| https://contoso.com | Допустимо |
| https://contoso.com/abc/response-oidc | Допустимо |
| https://localhost | Допустимо |
| http://contoso.com/abc/response-oidc | Недопустимо |
| http://localhost | Допустимо |
| http://localhost/abc | Допустимо |
Исключения для localhost
В соответствии с разделами RFC 8252 8.3 и 7.3, для URI перенаправления с замыканием на себя (localhost) действуют два особых правила:
С точки зрения разработки это означает несколько моментов:
Это особенно важно, если вы планируете использовать в одном зарегистрированном приложении разные потоки проверки подлинности (например, и выдачу кода авторизации, и неявный поток). Чтобы связать с каждым URI перенаправления правильные параметры ответа, сервер входа должен иметь возможность различать эти URI, что невозможно, если различается только порт.
IPv6-адрес замыкания на себя ( [::1] ) в настоящее время не поддерживается.
Выбор 127.0.0.1 вместо localhost
При этом текстовое поле URI перенаправления на портал Azure нельзя использовать для добавления URI замыкания на себя со схемой :
Ограничения на подстановочные знаки в URI перенаправления
URI с подстановочными знаками в настоящее время не поддерживаются для зарегистрированных приложений, настроенных для входа как в личные, так и в рабочие и учебные учетные записи Майкрософт. Однако подстановочные знаки в URI разрешены для приложений, которые настроены для входа только в рабочие или учебные учетные записи в арендаторе Azure AD организации.
Чтобы добавить URI перенаправления с подстановочными знаками для зарегистрированных приложений, которые входят в рабочие или учебные учетные записи, используйте редактор манифеста приложения в разделе Регистрация приложений на портале Azure. Хотя с помощью редактора манифеста действительно можно задать URI перенаправления с подстановочными знаками, мы настоятельно рекомендуем придерживаться требований раздела 3.1.2 RFC 6749 и использовать только абсолютные URI.
Если вам требуется больше URI перенаправления, чем разрешено, вместо подстановочных знаков вы можете воспользоваться следующей схемой с параметром состояния.
Использование параметра состояния
Если у вас есть несколько поддоменов и вам необходимо после успешной проверки подлинности перенаправлять пользователей на ту же страницу, с которой они начали, можно использовать параметр состояния.
Если вы используете этот подход:
Такой подход позволяет скомпрометированному клиенту изменять дополнительные параметры, отправляемые в параметре состояния, поэтому пользователь перенаправляется на другой URL-адрес, что является угрозой открытого перенаправления, как описано в стандарте RFC 6819. Таким образом, клиент должен защищать эти параметры, шифруя состояние или проверяя его с помощью других средств, таких как проверка доменного имени в URI перенаправления по маркеру.
Безопасность OAuth2
Данная блогозапись на хабр прежде всего обусловлена появлением «Ключницы» — хороший повод связать и перевести накопленное.
У нас в программе: вольный пересказ спек OAuth2, слабые стороны и Threat Model, 0day на хабретрюк с аутенфикацией.
OAuth2 это просто
Длинный, но правильный путь изучить его.
Для ленивых я опишу своими словами Authorization Code Flow как самый распространенный и безопасный, aka Server-Side.
Ключевые понятия — Клиент(website/online game/app), Юзер(you), Провайдер(facebook/vkontakte/google), Код(code) и Токен(access_token).
Клиент посылает Юзера — «авторизуй меня для доступа к твоим ресурсам». Юзер идет по ссылке к провайдеру, смотрит что от него требуют — scope параметр — жмет Разрешить. Далее Провайдер редиректит его назад на указанный redirect_uri на домене Клиента со следующими параметрами:
code — идентификатор Юзера у Провайдера, который нужен Клиенту чтобы получить Токен
state — то же значение что было передано на начальный URL. используется для защиты от CSRF и для удобства.
Код из себя не представляет никакой ценности для Юзера(и User-Agent соответственно) т.к. с его помощью нельзя совершать запросы API и нужен он лишь для одной цели — получения Токена.
Для получения Токена Клиент производит запрос на определенный эндпоинт, передав client_id, client_secret, code, redirect_uri по которому был получен код — таким образом Провайдер уверен что это нужный Клиент и по Коду он отдает Токен того самого Юзера. Как видите ни Юзер, ни User-Agent и клиентские скрипты не увидили настоящий Токен. Его знают только Клиент и Провайдер — в идеале.
Дальше Токен используют для совершения API запросов, впоследствии его можно рефрешить (для этого вместе с Токеном возвращается refresh_token).
Threat Model или Я Знаю О Чем Вы Подумали
1. А что если я подставлю такой redirect_uri который будет вести на свой сайт а потом использую этот Код сам для аутенфикации?
Все redirect_uri должны находится на домене Клиента. Часто разрешен еще домен Провайдера. Ваша ссылка вернет redirect_uri_mismatch.
2. ОК а что если я найду такое место на сайте Клиента, которое сольет мне Код? Может открытый редирект вида site.com?url=http://outsite.com или hot-linked картинку которая сольет реферер?
Каждый Код привязан к тому redirect_uri для которого он был выпущен и для получения Токена Клиент передает «правильный» redirect_uri. Если ваш Код был выпущен для clientsite.com/leak_referer а Клиент при получении Токена отошлет clientsite.com/facebook_callback то Провайдер не отдаст Токен.
3. А можно ли как то слить Код передав правильный redirect_uri?
Нет, т.к. любая правильная реализация Клиента обязана сразу редиректить на другую страницу после получения Кода — так что Код не виден даже в истории браузера.
Даже если вам удалось достать код для правильного redirect_uri то т.к. он уже был 1 раз использован он больше не активен.
4. Допустим у меня есть Код для моего аккаунта в соц сети выпущенный для правильного redirect_uri. Что будет если я заставлю посетить эту ссылку Васю?
В таком случае сайт Клиента подумает что ваш аккаунт в соц сети принадлежит Васе. И присоеденит его. Чтобы типичного CSRF не происходило Клиент обязан сохранять рандомное значение state в сессии/куке и проверять по возврату на колбэк на соответствие. Хотя, так почти никто не делает (точнее не делали).
Реальность
FB Reply Attack
Hijacking Account
Самая частая уязвимость, присутствует например на хабре — об этом ниже. Нарушается пункт 4.
Если вы видите в запросе state не спешите сдаваться. Что хабр, что digg.com не видели разницы между a12b6467c3fb385e237109502277ab26 и heyman0day123123
VK redirect_uri
Если вы используете Implicit Flow — т.е. получаете access_token от юзера напрямую, то нет никаких гарантий что этот токен принадлежит текущему юзеру. Он мог его просто украсть через вредоносного Клиента, и использовать чтобы попасть в аккаунт какого-то юзера на вашем сайте.
Обязательно проверяйте, был ли выпущен данный токен для вашего client_id.
Так же OAuth2 не дает никаких гарантий что пользователь дал вам те разрешения что вы запросили на этапе авторизации в параметре scope. Он мог просто удалить их — в итоге вы должны на колбэке проверить разрешил ли он что вы запросили.
Если на сайте найдена XSS то есть легкий способ украсть кучу access_token-ов. Возьмите authorize URL который сайт использует для facebook и замените response_type=code на token. Осталось вставить этот URL во фрейм, дождаться возврата токена в ссылке вида callback#access_token=123, срезать токен и слить его. Спамьте на здоровье!
0day на хабре?
Тот же эксплоит работает и для facebook/google только сложнее получить redirect_uri с кодом без использования его — нужен NoRedirect+FF
Поэтому демо на VK. дяденька не бань UPD: уязвимость исправили.
1. У вас не должно быть привязанного VK. Авторизуйтесь oauth.vk.com/authorize?response_type=code&client_id=3110645&redirect_uri=http%3A%2F%2Fhabrahabr.ru&scope=offline&display=page
2. Вас вернуло на habrahabr.ru/?code=CODE
3. Заставьте другого хабраюзера посетить habrahabr.ru/social/callback/vkontakte/?code=CODE&state=whogivesafuckaboutstate можно подкинуть саму ссылку, но лучше спрятать в img или iframe и тд. Если он залогинен на хабре ваш ВК привяжен к его хабрааккаунту.
4. Логинимся через ваш ВК в его хабрааккаунт, меняем его аватар на nayncat.
Мораль
Вконтакте: перестаньте игнорировать письма в Поддержку, либо попросите ваших разработчиков снизойти поговорить с простым смертным. А еще введите bounty program (sarcasm: есть риск разориться на ней).
Хабр: рекомендую выключить Ключницу на время и пофиксить уязвимость путем правильной проверки ‘state’ со значением из cookie/session.
Road to Hell короче. Вы можете присоедениться к разработке принципиально нового стандарта с нескучными токенами — OAuth2.a (Charm — Provider). Печенек, правда, нет.
Egor Homakov (@homakov) & isciurus #RT pls
Перенаправления в HTTP
URL перенаправление (redirecting), также известное как URL пересылка (forwarding), это метод представления страницы, формы или целого веб-приложения, более чем одним URL адресом. HTTP предоставляет специальный вид ответов, HTTP redirect, для выполнения этой операции, используемой для многих целей: временного перенаправления, пока выполняется обслуживание сайта, постоянное перенаправление, для сохранения работоспособности внешних ссылок, после смены архитектуры сайта, страниц прогресса, пока загружается файл, и так далее.
Принцип работы
Есть несколько типов перенаправлений и делятся на три категории: постоянные, временные и специальные перенаправления.
Постоянные перенаправления
Эти перенаправления призваны длиться вечно. Они подразумевают, что оригинальный URL-адрес больше не должен использоваться, а вместо него должен быть использован новый. Поисковые роботы запускают обновление связанного URL-адреса для ресурса в своих индексах.
[1] Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 308 был создан чтобы избавиться от неоднозначности в поведении, при использовании не- GET методов.
Временные перенаправления
Иногда, доступ к запрашиваемому ресурсу не может быть предоставлен из определённого места, но может быть предоставлен из другого. В этом случае, могут быть использованы временные перенаправления. Поисковые роботы не запоминают новую, временную ссылку. Временные перенаправления также используются, когда создаются, обновляются, или удаляются ресурсы, которые представляют временные страницы.
[2] Спецификация не была намерена разрешать изменение метода, но на практике, клиентские приложения делают это. Код 307 был создан чтобы избавиться от неоднозначности в поведении, при использовании не- GET методов.
Специальные перенаправления
В добавок к обычным перенаправлениям, есть 2 специальные. Перенаправление с кодом 304 (Not Modified) перенаправляет страницу к локальной закешированной копии (которая была устаревшей), и перенаправление с кодом 300 (Multiple Choice) это ручное перенаправление: тело, представленное браузером, как веб-страница, перечисляет возможные перенаправления и пользователь выбирает одно из них.
Альтернативные способы указания перенаправлений
HTML перенаправления
Атрибут content начинается с числа, которое означает, сколько секунд браузер должен ждать, прежде чем перейти по данной ссылке. Всегда устанавливайте 0, для лучшей доступности.
Очевидно, этот метод работает только с HTML страницами и не может использоваться для изображений или другого типа контента.
Заметьте, что перенаправления не позволяют работать должным образом кнопке «Назад» в браузере: вы можете вернуться на страницу назад, но мгновенно будете перенаправлены на страницу с которой пришли.
JavaScript перенаправления
Перенаправления в JavaScript создаются установкой значения свойства window.location и новая страница загрузиться.
Как и HTML перенаправления, этот тип не будет работать на всех ресурсах, и очевидно, что работает только на стороне клиента, который выполнит JavaScript. С другой стороны, вы можете вызвать перенаправление, только тогда, когда исполнится определённое условие.
Приоритетность
При использовании трёх возможных способов URL перенаправления, некоторые методы могут быть вызваны одновременно, но какой из них будет примёнён первым? Порядок приоритетов следующий:
Случаи использования
Есть много случаев для использования перенаправлений, но поскольку они влияют на производительность, то должны использоваться как можно реже.
Связывание доменов
В идеале, есть только одно место, и следовательно один URL адрес, для одного ресурса. Но, есть несколько причин, чтобы иметь альтернативные имена для ресурса (несколько доменов, как с, так и без префикса www или более короткие и лёгкие для запоминания адреса, …). В этих случаях, использовать перенаправление к одному истинному URL адресу, более подходящий вариант, чем дублировать ресурс.
Связывание доменов может быть необходимым по нескольким причинам:
Сохранения ссылок рабочими
Когда вы изменяете структуру веб-сайта, URL адреса ресурсов меняются. Даже, если вы можете обновить внутренние ссылки вашего сайта в соответствии с новой схемой имён, у вас нет контроля на URL адресами используемыми внешними ресурсами. Вы не хотите, чтобы эти ссылки не работали, так как они приносят вам ценных пользователей (и помогают вашей SEO), так что вы устанавливаете перенаправления из старых URL адресов на новые.
Не смотря на то, что данный метод работает также для внутренних ссылок, вы должны избегать внутренних перенаправлений. Перенаправления имеют большое влияние на производительность, и если вы имеете возможность избежать их, корректируя внутренние ссылки, тогда делайте так.
Временные ответы для небезопасных запросов
В этом случае, сервер вернёт ответ 303 (Смотреть другие), который будет содержать правильную информацию, но если кнопка перезагрузки будет нажата, эта страница просто отобразится повторно без ответа на небезопасный запрос.
Временные ответы на долгие запросы
Настройка перенаправлений на распространённых серверах
Apache
У модуля mod_alias есть директивы Redirect и Redirect_Match которые, по умолчанию, устанавливают код ответа 302 :
URL http://example.com/ будет перенаправлен к http://www.example.com/ (но не к http://example.com/other.html )
Redirect_Match делает то же, но использует регулярное выражение, чтобы определить множество URL адресов, которые подпадут под эффект:
Все документы в папке images/ будут перенаправляться к другому домену.
Если вы не хотите устанавливать временное перенаправление, дополнительный параметр (используйте или код статуса HTTP, или ключевое слово permanent) может использоваться чтобы установить другое перенаправление:
Также модуль mod_rewrite может использоваться для создания перенаправлений. Они более гибкие, но сложнее в использовании.
Nginx
В Nginx, вы создаёте особый серверный блок для контента, который вы хотите перенаправлять:
Чтобы применить перенаправления к папке или подмножеству страниц, используйте директиву rewrite :
В IIS, вы используете элемент для настройки перенаправлений.
Циклы перенаправлений
Циклы перенаправлений случаются когда за успешным перенаправлением следует другое, которое уже было выполнено. Другими словами, существует такой цикл, который никогда не закончится и в конечном счёте ни одна страница не будет найдена.
В случае, когда сервер не может обнаружить его: цикл перенаправлений может распространиться на несколько серверов, каждый из которых не имеет полной картины происходящего. В этом случае, браузеры покажут сообщение об ошибке. Firefox выведет:
В обоих случаях, пользователь не может ничего сделать (в отличие от ошибки на стороне клиента, например, несоответствие файлов куки или кеша).
Важно избегать циклов перенаправлений, так как они полностью нарушают работу пользователя.
Иллюстрированное руководство по 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 к списку контактов? — Спасибо! Теперь мы каждый день будем слать напоминания всем, кого вы знаете, до скончания веков! Вы самый лучший друг!»
Поток OAuth
Только что мы прошли через то, что обычно называют потоком [flow] OAuth. В нашем примере этот поток состоит из видимых шагов, а также из нескольких невидимых шагов, в рамках которых два сервиса договариваются о безопасном обмене информацией. В предыдущем примере с Terrible Pun of the Day используется наиболее распространенный поток OAuth 2.0, известный как поток «с кодом авторизации» [«authorization code» flow].
Прежде чем углубиться в подробности работы OAuth, давайте поговорим о значении некоторых терминов:
Ключ, который клиент будет использовать для связи с Resource Server‘ом. Этакий бейдж или ключ-карта, предоставляющий Client‘у разрешения на запрос данных или выполнение действий на Resource Server‘е от вашего имени.
Примечание: иногда Authorization Server и Resource Server являются одним и тем же сервером. Однако в некоторых случаях это могут быть разные серверы, даже не принадлежащие к одной организации. Например, Authorization Server может быть сторонним сервисом, которому доверяет Resource Server.
Теперь, когда мы ознакомились с основными понятиями OAuth 2.0, давайте вернемся к нашему примеру и подробно рассмотрим, что происходит в потоке OAuth.
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 разработан только для авторизации — для предоставления доступа к данным и функциям от одного приложения другому. OpenID Connect (OIDC) — это тонкий слой поверх OAuth 2.0, добавляющий сведения о логине и профиле пользователя, который вошел в учетную запись. Организацию логин-сессии часто называют аутентификацией [authentication], а информацию о пользователе, вошедшем в систему (т.е. о Resource Owner‘е), — личными данными [identity]. Если Authorization Server поддерживает OIDC, его иногда называют поставщиком личных данных [identity provider], поскольку он предоставляет Client‘у информацию о Resource Owner‘е.
OpenID Connect позволяет реализовывать сценарии, когда единственный логин можно использовать во множестве приложений, — этот подход также известен как single sign-on (SSO). Например, приложение может поддерживать SSO-интеграцию с социальными сетями, такими как Facebook или Twitter, позволяя пользователям использовать учётную запись, которая у них уже имеется и которую они предпочитают использовать.
Так же, как и в потоке OAuth, Access Token в OpenID Connect — это некое значение, не понятное Client‘у. С точки зрения Client‘а Access Token представляет некую строку из символов, которая передается вместе с каждым запросом к Resource Server‘у, а тот определяет, действителен ли токен. 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] от Authorization Server‘а, например, адрес электронной почты, используя Access Token.
Дополнительные сведения об OAuth и OIDC
Итак, мы вкратце рассмотрели принципы работы OAuth и OIDC. Готовы копнуть глубже? Вот дополнительные ресурсы, которые помогут узнать больше об OAuth 2.0 и OpenID Connect:
