Медленно, но неотвратимо наступает смена решений SSO на основе SAML на решения OpenID стека. С недавних пор компания Google реализовала поддержку OpenID Connect протокола на своих серверах. Насколько он может быть приемлем для Вашего проекта и как с ним работать, оценить по спецификации протокола довольно трудно. Немного облегчить это решение должна статья одного из авторов спецификации в своём блоге, перевод которой я и предоставляю аудитории хабра. В целях упростить понимание, некоторые моменты были добавлены от себя, таким образом, чтобы не приходилось обязательно читать ссылки на используемые технологии, но ознакомится с некоторыми из них всё же я рекомендую. Когда вы читаете спецификацию по OpenID Connect, вы можете испытывать довольно неприятные чувства от лёгкой испуганности до полнейшего разочарования. Всё это происходит потому, что они написаны на “сухом” языке спецификации, и по большей части они описывают граничные случаи, исключения и т.д. Тем не менее, когда вы переводите их на нормальный человеческий язык и переключаетесь на конкретные случаи, всё становится довольно очевидно. Итак, давайте приступим! (Ремарочка: большая часть текста совпадает с первоначальным предложением, написанным Дэвидом Рекордоном. В основном, мои правки затронули лишь некоторые из имен параметров и другие мелочи) Для того, чтобы клиент мог совершить OpenID Connect запрос, он должен иметь следующую информацию о сервере: Для того чтобы превратить запрос OAuth 2.0 в запрос OpenID Connect, просто добавьте ключ OpenID в качестве одной из требуемых наборов данных (параметр scope). Установив в параметре ключ OpenID, клиент запрашивает идентификатор для пользователя, а также контекст аутентификации. Если вы хотите получить URL профиля пользователя, имя или фотографию, вы можете запросить дополнительные наборы данных (к примеру — профиль). Сервер (и пользователь) может выбирать информацию о профиле доступном клиенту. Если клиент хочет получить адрес электронной почты пользователя, он должен добавить ключ “email” в запросе. То же самое относится и к адресу (address) и телефону (phone).
Например: Несмотря на то, что предварительная регистрация вашего клиента на сервере может быть не обязательна, вполне вероятно, что сервера будут иметь различные ограничения и требования к клиентам для запросов к информации пользователей. Если пользователь будет авторизован клиентским запросом, то клиент получит токен. Ответ авторизации 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 провайдеров. Software Developer