openid connect что это

Иллюстрированное руководство по 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:

Источник

Платформа удостоверений Майкрософт и протокол OpenID Connect

OpenID Connect (OIDC) — это протокол проверки подлинности на основе OAuth 2.0, который можно использовать для безопасного входа пользователей в приложение. Если вы используете реализацию OpenID Connect на основе платформы удостоверений Майкрософт, в приложениях можно настроить функции входа и доступа к API. В этой статье приведены сведения, которые применимы для любого языка, а также описывается, как отправлять и получать сообщения HTTP, не используя ни одну из библиотек с открытым кодом корпорации Майкрософт.

OpenID Connect расширяет возможности протокола авторизации OAuth 2.0 и позволяет использовать его в качестве протокола проверки подлинности, что дает возможность выполнять единый вход с помощью OAuth. В OpenID Connect вводится понятие маркера идентификации, который представляет собой маркер безопасности, позволяющий клиенту проверять личность пользователя. Маркер идентификации также позволяет получить базовые сведения о профиле пользователя. Еще одним новым понятием является конечная точка UserInfo — API, возвращающий сведения о пользователе.

Попробуйте выполнить этот запрос и многое другое в Postman — не забудьте заменить токены и идентификаторы!

Схема протокола. Вход

На следующей схеме показаны этапы самого простого потока входа. Каждый этап подробно описан в этой статье.

Получение документа метаданных OpenID Connect

OpenID Connect описывает документ метаданных (RFC), который содержит большинство сведений, необходимых приложению для входа. Сюда входят такие сведения, как используемые URL-адреса и расположение открытых ключей подписывания службы. Этот документ можно найти, добавив путь документа обнаружения в URL-адрес центра авторизации:

Путь документа обнаружения: /.well-known/openid-configuration

Центр авторизации: https://login.microsoftonline.com//v2.0

может принимать одно из четырех значений.

Пример запроса

Чтобы вызвать конечную точку UserInfo для общего центра авторизации в общедоступном облаке, используйте следующую команду:

Пример ответа

Метаданные — это простой документ JSON. В качестве примера ниже приведен фрагмент кода. Его содержимое полностью описано в спецификации OpenID Connect.

Как правило, этот документ метаданных используется для настройки библиотеки OpenID Connect или пакета SDK. Метаданные будут использоваться для работы библиотеки. Тем не менее, если вы не используете готовую библиотеку OpenID Connect, выполните инструкции в оставшейся части этой статьи, чтобы войти в веб-приложение с помощью платформы удостоверений Майкрософт.

Отправка запроса на вход

Чтобы успешно выполнить запрос маркера идентификации из конечной точки /authorization, на вкладке «Проверка подлинности» для регистрации приложения на портале регистрации нужно включить неявное предоставление разрешения id_tokens (что устанавливает флаг в манифесте приложения равным ). Если его не включить, возникнет следующая ошибка unsupported_response : «The provided value for the input parameter ‘response_type’ isn’t allowed for this client. Expected value is ‘code'» (Указанное значение параметра response_type запрещено для данного клиента. Ожидаемое значение: code).

Успешный ответ

Успешный ответ при использовании response_mode=form_post выглядит следующим образом.

Сообщение об ошибке

Сообщения об ошибках также можно отправлять на универсальный код ресурса (URI) перенаправления, чтобы приложение могло их обработать. Сообщение об ошибке выглядит следующим образом.

Коды ошибок конечной точки авторизации

В таблице ниже описаны коды ошибок, которые могут возвращаться в параметре error сообщения об ошибке.

Проверка маркера идентификации

Для аутентификации пользователя не всегда достаточно просто получить токен id_token. Вам также может потребоваться проверить подпись токена id_token и утверждения в нем в соответствии с требованиями приложения. Как и все платформы OIDC, платформа удостоверений Майкрософт использует для подписи маркеров ИД и проверки их правильности веб-токены JSON (JWT) и шифрование с открытым ключом.

Однако, преимущества от проверки маркера ИД получают не все приложения, например, для собственных и одностраничных приложений такая проверка очень редко является полезной. Пользователь с физическим доступом к устройству (или браузеру) может обойти проверку различными способами — от изменения веб-трафика для устройства, чтобы предоставить фиктивные токены и ключи, и до отладки приложения таким образом, чтобы пропустить логику проверки. С другой стороны, веб-приложения и API, использующие маркер ИД для авторизации, должны тщательно проверять маркер ИД, так как они предоставляют доступ к данным.

После проверки подписи токена id_token вам потребуется проверить несколько утверждений. См. справочник по и дополнительные сведения о проверке маркеров и смене ключей подписывания. Советуем использовать библиотеку для синтаксического анализа и проверки токенов. Для большинства языков и платформ доступна по крайней мере одна такая библиотека.

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

После полной проверки токена id_token вы можете начать сеанс с пользователем и использовать утверждения в токене id_token для получения сведений о пользователе в приложении. Эти сведения можно использовать для отображения, регистрации, персонализации и т. д.

Схема протокола. Получение маркера доступа

Многим веб-приложениям требуется не только выполнить вход пользователя, но и получить доступ к веб-службе от имени этого пользователя с помощью OAuth. Этот сценарий совмещает применение OpenID Connect для аутентификации пользователей и одновременное получение кода авторизации, который можно использовать для получения маркеров доступа с помощью потока кода авторизации OAuth.

Полный поток входа OpenID Connect и получения маркера представлен на следующей схеме. Каждый этап подробно описан в следующих разделах статьи.

Получение маркера доступа для вызова UserInfo

Чтобы получить маркер для конечной точки UserInfo OIDC, измените запрос на вход:

Чтобы получить маркер для приложения, вместо можно также использовать поток кода авторизации, поток кода устройстваили маркер обновления.

Успешный ответ маркера

Успешный ответ с использованием response_mode=form_post выглядит следующим образом.

Параметры ответа означают одно и то же, независимо от потока, используемого для их получения.

Не пытайтесь проверить или прочесть маркеры для любого API, который вам не принадлежит, включая маркеры в этом примере, в коде. Маркеры для служб Майкрософт могут использовать специальный формат, который не будет проверяться как JWT и может также быть зашифрован для пользователей-потребителей (учетная запись Майкрософт). Несмотря на то, что чтение маркеров является полезным средством отладки и обучения, не задавайте зависимости от него в коде или не опирайтесь на конкретные сведения о токенах, которые не предназначены для контролируемого вами API.

Сообщение об ошибке

Сообщения об ошибках также можно отправлять на универсальный код ресурса (URI) перенаправления, чтобы приложение могло их правильно обработать. Сообщение об ошибке выглядит следующим образом.

Описание возможных кодов ошибок и рекомендуемые ответы клиента см. в разделе Коды ошибок конечной точки авторизации.

После получения кода авторизации и маркера идентификации можно выполнить вход пользователя в систему и получить маркеры доступа от его имени. Для входа пользователя необходимо проверить маркер идентификации в точности, как описано выше. Для получения маркеров доступа следует выполнить действия, описанные в документации по потоку кода OAuth.

Вызов конечной точки UserInfo

Просмотрите документацию по UserInfo, чтобы узнать, как вызвать конечную точку UserInfo с помощью этого маркера.

Отправка запроса на выход

Для выхода пользователя из приложения недостаточно очистить файлы cookie или каким-то другим образом завершить сеанс пользователя. Необходимо также перенаправить пользователя на платформу удостоверений Майкрософт для выхода. Если этого не сделать, то пользователь сможет проходить повторную аутентификацию без ввода учетных данных, так как для него сохранится действительный сеанс единого входа на платформе удостоверений Майкрософт.

Можно перенаправить пользователя на адрес, указанный в параметре end_session_endpoint в документе метаданных OpenID Connect:

Единый выход

Источник

Вкратце об OpenID Connect

Медленно, но неотвратимо наступает смена решений SSO на основе SAML на решения OpenID стека. С недавних пор компания Google реализовала поддержку OpenID Connect протокола на своих серверах. Насколько он может быть приемлем для Вашего проекта и как с ним работать, оценить по спецификации протокола довольно трудно. Немного облегчить это решение должна статья одного из авторов спецификации в своём блоге, перевод которой я и предоставляю аудитории хабра. В целях упростить понимание, некоторые моменты были добавлены от себя, таким образом, чтобы не приходилось обязательно читать ссылки на используемые технологии, но ознакомится с некоторыми из них всё же я рекомендую.

Когда вы читаете спецификацию по OpenID Connect, вы можете испытывать довольно неприятные чувства от лёгкой испуганности до полнейшего разочарования. Всё это происходит потому, что они написаны на “сухом” языке спецификации, и по большей части они описывают граничные случаи, исключения и т.д. Тем не менее, когда вы переводите их на нормальный человеческий язык и переключаетесь на конкретные случаи, всё становится довольно очевидно. Итак, давайте приступим! (Ремарочка: большая часть текста совпадает с первоначальным предложением, написанным Дэвидом Рекордоном. В основном, мои правки затронули лишь некоторые из имен параметров и другие мелочи)

Создание запроса OpenID Connect

Для того, чтобы клиент мог совершить OpenID Connect запрос, он должен иметь следующую информацию о сервере:

Построение клиентом запроса OAuth 2.0, для получения токена.

Для того чтобы превратить запрос OAuth 2.0 в запрос OpenID Connect, просто добавьте ключ OpenID в качестве одной из требуемых наборов данных (параметр scope). Установив в параметре ключ OpenID, клиент запрашивает идентификатор для пользователя, а также контекст аутентификации. Если вы хотите получить URL профиля пользователя, имя или фотографию, вы можете запросить дополнительные наборы данных (к примеру — профиль). Сервер (и пользователь) может выбирать информацию о профиле доступном клиенту. Если клиент хочет получить адрес электронной почты пользователя, он должен добавить ключ “email” в запросе. То же самое относится и к адресу (address) и телефону (phone).
Например:

Несмотря на то, что предварительная регистрация вашего клиента на сервере может быть не обязательна, вполне вероятно, что сервера будут иметь различные ограничения и требования к клиентам для запросов к информации пользователей.

Получение OpenID Connect ответа

Если пользователь будет авторизован клиентским запросом, то клиент получит токен. Ответ авторизации OAuth 2.0 как правило, включает в себя два параметра: access_token и id_token. Информация в id_token закодирована и включает в себя объект JSON с такими полями:

Параметр id_token представляет простой способ, чтобы убедиться, что данные, полученные клиентом через User-Agent потоки (или других ненадежных каналов) не были изменены. Параметр подписывается сервером, используя клиентский ключ, который был ранее передан через доверенный канал. Эта кодировка называется JSON Web Токен (о JWT вкратце и черновая спецификация). К примеру, вот такая строка :

Она состоит из трёх частей которые отделены точками.
Первая часть — заголовок (Header), это JSON объект закодированный Base64url и описывающий алгоритм и тип токена:

Вторая часть — полезная нагрузка (Payload), это так-же JSON объект закодированный Base64url:

Третью часть сервер получил след образом:

Обратите внимание, что base64url кодировка в отличии от base64 использует два других символа и не содержит отступов.
Сервер авторизации должен выдавать подтверждения об идентификаторах пользователей только в пределах своих доменов. Клиент в свою очередь должен убедиться, что aud соответствует его client_id, а iss соответствует домену (включая суб-домен) эмитента в client_id. Сервер авторизации отвечает за управление собственным локальным пространством имен и обеспечивает локальную уникальность и неповторяемость (непереназначаемость) каждого user_id.
Когда клиент сохраняет идентификатор пользователя, он должен сохранить кортеж из user_id и iss в своём локальном хранилище. Параметр user_id должен не превышать 255 ASCII символов в длину.
Что-бы удостовериться в аутентичности данных клиент может проверить подпись. Если клиент не проверяет подпись, он должен выполнить HTTP запрос к точке проверки идентификатора, чтобы проверить его. — немножко непонятно зачем ему это делать

Доступ к информации о пользователях (опционально)

Информация о пользователе является обычным OAuth 2.0 ресурсом, который возвращается вместе с токеном в виде документа в формате JSON. Клиент делает HTTPS «GET» запрос по адресу предоставления пользовательской информации и включает в себя токен в качестве параметра.
Ответ представляет собой объект JSON, который содержит некоторые (или все) из следующих зарезервированных ключей (json-объекта):

Сервер по необходимости может добавить дополнительные данные в этот ответ (к примеру такие как переносимые контакты) пока они не изменяют зарезервированные ключи OpenID Connect. (Примечание: есть более четко определенные ключи, но для краткости, я опущу их описание.)

Открытие (опционально)

При использовании OpenID Connect вполне вероятно, что клиент может иметь или кнопки для регистрации через популярные сервисы, или текстовое поле для ввода адреса электронной почты или URL. OpenID Connect напрямую не решает проблему NASCAR
(Проблема NASCAR — это отсылка на мешанину из значков брендов веб-сайтов, через которые осуществляется вход, подчёркивая схожесть страницы логина с коллажами наклеек спонсорской рекламы на трековых автомобилях в гонках NASCAR).
Цель этапов открытия и регистрации для клиента состоит в том, чтобы получить адрес сервера авторизации, конечный адрес точки выдачи токена, идентификатора клиента, секрет клиента, и получения API пользовательских данных. Если клиент предварительно зарегистрирован на сервере, то эта информация уже будет известна. В противном случае клиенту нужно будет получить их при помощи этапа открытия.
Пользователь нажимает на кнопку на клиенте, чтобы выбрать сервер. В этом случае разработчик клиента сможет выбрать предпочтительные сервера и таким образом, уже зная их адреса авторизации (и, возможно, другую информацию). Клиент может быть или не быть предварительно зарегистрированным.
В другом случае, пользователь (или User-Agent, действующим от его имени) вводит URL или адрес электронной почты. Для этого клиенту необходимо будет выполнить обнаружение и определить, является ли валидным URL-адрес сервера авторизации. Шаги:

Ответ представляет собой объект JSON, который включает в себя конечную точку и другую информацию.
Например:

Незарегистрированные клиенты и динамическая регистрация (опционально)

Независимо от используемого механизма обнаружения (Discovery), клиент может быть или не быть уже зарегистрирован на сервере. Сервера могут иметь разные ограничения на то, какую информацию могут получить клиенты в зависимости от того, являются ли они предварительно зарегистрированными (что подразумевает согласие на условия предоставления услуг) или клиент использует динамическую регистрацию.
Если клиент не имеет валидный идентификатор клиента и ключ, он может сделать следующий HTTPS POST запрос на адрес регистрации сервера (см. Открытие) со перечисленными запрашиваемыми параметрами в формате JSON в теле POST запроса: redirect_uris — Массив URL адресов для получения ответов OpenID.
Например:

Перед тем, как ответить на запросы, сервер должен проверить, зарегистрирован ли URL коллбек за пределами этого потока OpenID. Если да, сервер отправит информацию с реакцией на ошибку. Серверу необходимо будет разработать политику для обработки таких случаев, когда переданные redirect_uri были предварительно зарегистрированы разработчиком клиента, при запросах динамической регистрации. Такое поведение может означать, к примеру, что новые запросы динамической регистраций с этими redirect_uri приведут к ошибке, но запросы с использованием уже осуществлённой динамической регистраций продолжат работать, пока не устареют.
Для обеспечения динамической ассоциации, сервер включает в себя следующие параметры ответа JSON:

Клиенту необходимо хранить свои данные динамической регистрации для работы с токенами сервера. Для каждой динамической регистрации клиенту необходимо будет хранить идентификатор клиента, ключ клиента, время истечения, пользовательский URL, поддерживаемые потоки, а также API пользовательской информации. Время окончания срока следует хранить как абсолютное время или метку того, что регистрация будет длится вечно.
Как видите, основные процессы веб-клиента OpenID Connect достаточно просты, и так же просты, как те, которые предлагались первоначально. В то же время, могут быть использованы дополнительные функциональные возможности, например запрос конкретных наборов данных, а не набор по умолчанию. Эти дополнительные возможности доступны, когда они необходимы и не превращают простые взаимодействия в крупные проблемы для клиентов, с большим числом OpenID провайдеров.

Источник