Xsolla Documentation – Как подключить бесшовную авторизацию

Что такое оauth2.0?

Разработку нового Auth мы решили начать с изучения доступных протоколов и технологий. Самый распространённый стандарт авторизации — фреймворк авторизации OAuth2.0. 

Стандарт был принят в 2022 году, и за 8 лет протокол меняли и дополняли. RFC стало настолько много, что авторы оригинального протокола решили написать OAuth 2.1, который объединит все текущие изменения по OAuth 2.0 в одном документе. Пока он на стадии черновика.

Актуальная версия OAuth описанна в RFC 6749. Именно его мы и разберем. 

OAuth 2.0 — это фреймворк авторизации.

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

Особенности:

Разберёмся подробнее в особенностях.

Основные понятия

Прежде чем начать разбираться с решениями и подходами следует определиться в терминах и последовательности процессов:

Что такое grant?

Grant — это данные, которые представляют из себя успешную авторизацию клиента владельцем ресурса, используемые клиентом для получения access token.

Например, когда мы где-либо аутентифицируемся с помощью Google, перед глазами всплывает уведомление. В нём говорится, что такой-то сервис хочет получить доступ к данным о вас или к вашим ресурсам (выводятся запрашиваемые scope-token). Это уведомление называется «Consent Screen».

В момент, когда нажимаем «ОК», в базу данных попадает тот самый grant: записываются данные о том, что такой-то пользователь дал такие-то доступы такому-то сервису. Клиент получает какой-то идентификатор успешной аутентификации, например строку, которая ассоциируется с данными в базе данных.

Существует 4 1 способа получения grant — grant type:

§ классический пример

Крутой проектировщик придумывает клевые сценарии. Он проводит UX-исследования разной степени извращенности. Он создает в своей голове идеальный мир. Мир, в котором данные передаются мгновенно, а состояния интерфейса обновляются в еще даже не открытой вкладке браузера.

Но тыква обращается крысой и до подошвы сгрызает туфельку — как только выясняется, что для реализации одного лишь обновления состояний необходимо потратить дополнительные 10 килобаксов. И даже они не спасают: пользователи вдруг прекращают выполнять целевое действие из-за того, что тупо не уверены, смогут ли продолжить его на смартфоне.

Вот и получается, что разработчики в спешном порядке вырубают синхронизацию, оставив ее «на потом». А CEO, вернувшийся с очередного бизнес-тренинга, велит немедленно прикрутить к сервису интеграцию с национальной нигерийской кредитной системой — и про «потом» благополучно забывают. Мир не-мертвых пополняется очередной зомби-функцией.

§ классический провал

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

Даже не самый вдумчивый читатель скажет, что я утрирую, сгущаю краски. И будет прав. Описанный выше «пример» намеренно карикатурен. Но согласитесь, почти у каждого была хотя бы одна из описанных в нем ситуаций.

§ причина вторая, техническая

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

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

Чем сложнее система, чем больше в ней сценарных разветвлений, тем менее вероятно, что весь комплекс функций будет работать слаженно. Вот и появляются дубликаты методов обмена данными, «утекающая» память устройств и прочие прелести, незаметно убивающие эффективность программистов и пользовательскую конверсию.

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

1. Синхронизация состояний интерфейса и результатов действий пользователя. До мелочей и желательно — в реальном времени. Если можно использовать WebSockets, снимается вопрос обмена данными, но не их обработки и сохранения.
2. Работа в оффлайне. Как заставить сайт корректно работать в условиях отсутствия связи, а при ее восстановлении благополучно отправлять данные на сервер? Тут на помощь приходят Service Workers, однако с ними не очень просто работать. Да и старые браузеры могут послать вас в довольно мрачное место.
3. Приоритизация источников данных. Например, данные с сайта отнюдь не всегда имеют такой же логический вес, как из мобильного приложения.
4. Откат и объединение изменений. В случае критических ошибок необходимо грамотно их обрабатывать. А обработав, пушить пользователя.
5. Производительность. Бывает так, что две разных функции начинают конфликтовать (например, используют один и тот же метод синхронизации). И здесь возможно все: от полного бездействия одной из них, до уже упомянутого яростного пожирания оперативки.

Как я уже сказал, таких задач намного больше, я описал типовые. А теперь умножьте их на количество мест в сценарии, где нужна синхронизация. Ощущаете прилив сил?

Даже если UX описан идеально, высока вероятность, что при реализации будет что-то упущено. И одна из причин таких упущений кроется в дизайнерах: далеко не каждый хотя бы пытается соотнести свои решения с техническими возможностями.

§ причина третья, финансовая

Ну тут все просто. Есть бабло — пилим фичу. Нет бабла — и так сойдет.

Или нет? А вообще, кто считает, есть ли бабло? Возьмем нашего среднего по больнице дизайнера. Он вообще думает о цифрах? Сколько денег бизнесу может принести функция? А сколько нужно на ее придумывание-разработку-внедрение? Конечно, нет, не думает. Пусть об этом думает CEO и его маркетологи. Они же «про бабло», а дизайн — «про пользователей». Так ведь?

Вообще, нет. Дизайн тоже «про бабло». Это касается не только бесшовного UX. Если есть сомнения в целесообразности той или иной функциональности — давайте просто посчитаем ее экономическую целесообразность. Это не сложно, я уже писал много раз об этом.

Иначе бизнес потратит некоторое количество своих финансовых сбережений на то, что может приносить ему весьма сомнительную пользу. И в какой-то момент он (бизнес) решит, что «данунафик». Причем это решение может снизойти прям перед релизом той самой фичи. И тогда мир не-мертвых… Ну вы поняли.

§ причины фэйла

А теперь к главному. Не все так плохо. Решение есть. Не «серебряная пуля», конечно, но в IT вообще не бывает универсальных и всеобъемлющих решений. Я предлагаю разобрать причины, по которым бесшовный UX дохнет — и малость расскажу о том, как этого избежать. А дальше вы сами.

§ резюмировали, резюмировали…

Специально для критиков: список причин, по которым может зафэйлится бесшовный UX, не уместится ни в одну статью. Здесь и кривой менеджмент, и несоответствие бизнес-требований реалиям, и ошибки позиционирования, и многое другое. Однако задачей этого материала не является предоставление универсальных методов решения. Я хочу лишь показать, куда копать. Ну а там дело за вами и вашей лопатой.

P.S. Возможно, стоит набросать отдельную статью с реальными примерами бесшовного взаимодействия. Если вам было бы интересно — го в комменты.

§ с — самонадеянность

То есть мы все знаем, что такое бесшовный опыт. Мы все его любим. Мы даже проектируем контекстное переключение между сервисами/приложениями/устройствами — и тратим порой на это довольно много времени. Так почему же бесшовное взаимодействие поддерживают лишь считанные единицы даже самых крутых наших продуктов?

Причин может быть несколько, и ниже я остановлюсь на каких-то из них подробнее. Однако есть одна главная, которая включает в себя все остальные — это невероятно сложно. Скажу даже больше: далеко не каждый проектировщик вообще способен придумать, проверить и правильно описать бесшовный UX. Хотя он сам чаще всего и считает иначе.

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

Есть один тонкий нюанс — помимо сценарной сложности и ада в реализации, каждый аспект бесшовного взаимодействия должен быть согласован и выверен. Такого рода проектирование — это почти всегда командная работа.

Authorization code

Самый распространённый flow на данный момент. В основном используется для confidential клиентов, но с появлением дополнительной проверки с помощью PKCE, может применяться и для public-клиентов. 

Jwt токен — состав

Заголовок

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

Тип токена хранится в ключе «typ». Ключ «typ» игнорируется в JWT. Если ключ «typ» присутствует, его значение должно быть JWT, чтобы указать, что этот объект является JSON Web Token.

Второй ключ «alg» определяет алгоритм, используемый для шифрования токена. По умолчанию он должен быть установлен в HS256. Заголовок кодируется в base64.

{ “alg”: “HS256”, “typ”: “JWT”}Payload (содержимое) — в полезной нагрузке хранится любая информация, которую нужно проверить. Каждый ключ в полезной нагрузке известен как «заявление». К примеру, в приложение можно войти только по приглашению (закрытое промо).

Когда мы хотим пригласить кого-то поучаствовать, мы отправляем ему письмо с приглашением. Важно проверить, что адрес электронной почты принадлежит человеку, который принимает приглашение, поэтому мы включим этот адрес в полезную нагрузку, для этого сохраним его в ключе «e-mail»

Jwt токен и его преимущества

JWT (JSON Web Token) — открытый стандарт (

Resource owner password credentials flow

По текущим рекомендациям безопасности описанных в

, данный flow не рекомендуется использовать вовсе из-за явных проблем с безопасностью.

Абстрактный oauth 2.0. flow c применением access token

Мы рассмотрели роли, рассмотрели виды токенов, а также как выглядят scope. Посмотрим на flow предоставления доступа к сервису.

Ниже представлена абстрактная схема (или flow) взаимодействия между участниками. Все шаги на данной схеме выполняются строго сверху вниз. Разберём детальнее.

Клиент получает одобрение от resource owner, на основе которого ему выдаётся доступ к ресурсу. Всё просто. А будет ли так же просто, если мы добавим в эту схему работу с refresh token?

Абстрактный oauth 2.0. flow c применением refresh token

Первый и второй шаги опущены из данной схемы — они ничем не отличаются от схемы абстрактного flow выше.

Схема подробнее:

Аутентификация по ключам доступа

Этот способ чаще всего используется для аутентификации устройств, сервисов или других приложений при обращении к веб-сервисам. Здесь в качестве секрета применяются ключи доступа (
access key, API key

Аутентификация по одноразовым паролям

Аутентификация по одноразовым паролям обычно применяется дополнительно к аутентификации по паролям для реализации
two-factor authentication
(2FA). В этой концепции пользователю необходимо предоставить данные двух типов для входа в систему: что-то, что он знает (например, пароль), и что-то, чем он владеет (например, устройство для генерации одноразовых паролей). Наличие двух факторов позволяет в значительной степени увеличить уровень безопасности, что м. б. востребовано для определенных видов веб-приложений.

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

Существуют разные источники для создания одноразовых паролей. Наиболее популярные:

1. Аппаратные или программные токены, которые могут генерировать одноразовые пароли на основании секретного ключа, введенного в них, и текущего времени. Секретные ключи пользователей, являющиеся фактором владения, также хранятся на сервере, что позволяет выполнить проверку введенных одноразовых паролей. Пример аппаратной реализаций токенов — RSA SecurID; программной — приложение Google Authenticator.
2. Случайно генерируемые коды, передаваемые пользователю через SMS или другой канал связи. В этой ситуации фактор владения — телефон пользователя (точнее — SIM-карта, привязанная к определенному номеру).
3. Распечатка или scratch card со списком заранее сформированных одноразовых паролей. Для каждого нового входа в систему требуется ввести новый одноразовый пароль с указанным номером.

Аппаратный токен RSA SecurID генерирует новый код каждые 30 секунд.

В веб-приложениях такой механизм аутентификации часто реализуется посредством расширения forms authentication: после первичной аутентификации по паролю, создается сессия пользователя, однако в контексте этой сессии пользователь не имеет доступа к приложению до тех пор, пока он не выполнит дополнительную аутентификацию по одноразовому паролю.

Аутентификация по сертификатам

Сертификат представляет собой набор атрибутов, идентифицирующих владельца, подписанный
certificate authority
(CA). CA выступает в роли посредника, который гарантирует подлинность сертификатов (по аналогии с ФМС, выпускающей паспорта). Также сертификат криптографически связан с закрытым ключом, который хранится у владельца сертификата и позволяет однозначно подтвердить факт владения сертификатом.

На стороне клиента сертификат вместе с закрытым ключом могут храниться в операционной системе, в браузере, в файле, на отдельном физическом устройстве (smart card, USB token). Обычно закрытый ключ дополнительно защищен паролем или PIN-кодом.

В веб-приложениях традиционно используют сертификаты стандарта X.509. Аутентификация с помощью X.509-сертификата происходит в момент соединения с сервером и является частью протокола SSL/TLS. Этот механизм также хорошо поддерживается браузерами, которые позволяют пользователю выбрать и применить сертификат, если веб-сайт допускает такой способ аутентификации.

Использование сертификата для аутентификации.

Во время аутентификации сервер выполняет проверку сертификата на основании следующих правил:

1. Сертификат должен быть подписан доверенным certification authority (проверка цепочки сертификатов).
2. Сертификат должен быть действительным на текущую дату (проверка срока действия).
3. Сертификат не должен быть отозван соответствующим CA (проверка списков исключения).

Пример X.509 сертификата.

После успешной аутентификации веб-приложение может выполнить авторизацию запроса на основании таких данных сертификата, как subject (имя владельца), issuer (эмитент), serial number (серийный номер сертификата) или thumbprint (отпечаток открытого ключа сертификата).

Использование сертификатов для аутентификации — куда более надежный способ, чем аутентификация посредством паролей. Это достигается созданием в процессе аутентификации цифровой подписи, наличие которой доказывает факт применения закрытого ключа в конкретной ситуации (non-repudiation).

Аутентификация по токенам

Такой способ аутентификации чаще всего применяется при построении распределенных систем
Single Sign-On
(SSO), где одно приложение (
service provider
или
relying party
) делегирует функцию аутентификации пользователей другому приложению (
identity provider
или
authentication service
). Типичный пример этого способа — вход в приложение через учетную запись в социальных сетях. Здесь социальные сети являются сервисами аутентификации, а приложение
доверяет
функцию аутентификации пользователей социальным сетям.

Реализация этого способа заключается в том, что identity provider (IP) предоставляет достоверные сведения о пользователе в виде токена, а service provider (SP) приложение использует этот токен для идентификации, аутентификации и авторизации пользователя.На общем уровне, весь процесс выглядит следующим образом:

1. Клиент аутентифицируется в identity provider одним из способов, специфичным для него (пароль, ключ доступа, сертификат, Kerberos, итд.).
2. Клиент просит identity provider предоставить ему токен для конкретного SP-приложения. Identity provider генерирует токен и отправляет его клиенту.
3. Клиент аутентифицируется в SP-приложении при помощи этого токена.

Пример аутентификации «активного» клиента при помощи токена, переданного посредством Bearer схемы.

Процесс, описанный выше, отражает механизм аутентификации активного клиента, т. е. такого, который может выполнять запрограммированную последовательность действий (например, iOS/Android приложения). Браузер же — пассивный клиент в том смысле, что он только может отображать страницы, запрошенные пользователем.

Пример аутентификации «пассивного» клиента посредством перенаправления запросов.

Существует несколько стандартов, в точности определяющих протокол взаимодействия между клиентами (активными и пассивными) и IP/SP-приложениями и формат поддерживаемых токенов. Среди наиболее популярных стандартов — OAuth, OpenID Connect, SAML, и WS-Federation. Некоторая информация об этих протоколах — ниже в статье.

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

При аутентификации с помощью токена SP-приложение должно выполнить следующие проверки:

1. Токен был выдан доверенным identity provider приложением (проверка поля issuer).
2. Токен предназначается текущему SP-приложению (проверка поля audience).
3. Срок действия токена еще не истек (проверка поля expiration date).
4. Токен подлинный и не был изменен (проверка подписи).

В случае успешной проверки SP-приложение выполняет авторизацию запроса на основании данных о пользователе, содержащихся в токене.

Балансировка нагрузки

Балансировщик нагрузки является единой точкой входа в keycloak и должен поддерживать sticky sessions.

Для кого подходит

Для партнеров, у которых уже подключены продукты Лаунчер и Авторизация Иксолла.

Доменная аутентификация ос при бесшовной интеграции 1с:документооборот 8 корп, редакция 2.1 и 1с:erp управление предприятием 2 (в клиент-серверном режиме)

Задача auth

Проблема авторизации в десятках сервисов встречалась ещё несколько лет назад — в начале «

». Эту проблему решили новым сервисом, который назвали – Auth. Он помог реализовать бесшовную аутентификацию в различных сервисах и перенести данные о пользователях в отдельные базы данных. 

У сервиса Auth есть три основные задачи:

Идентификационный брокер keycloak

Keycloak

— это решение для управления идентификацией и доступом с открытым исходным кодом, предназначенное для использования в ИС где могут использоваться паттерны микросервисной архитектуры.

Keycloak предлагает такие функции, как единый вход (SSO), брокерская идентификация и социальный вход в систему, федерация пользователей, клиентские адаптеры, консоль администратора и консоль управления учетными записями.

Базовый функционал, поддерживаемый в Keycloak:

Как настроить

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

Как это работает

Если пользователь авторизовался с помощью Авторизации Иксолла на сайте, распространяющем лаунчер, после установки приложения вход в аккаунт лаунчера выполняется автоматически.

Кнопка авторизации в эбс iprbooks[править]

Код кнопки:

Кнопка авторизации в эбс znanium[править]

Код кнопки:

Кнопка авторизации в эбс консультант студента[править]

На сегодня такую кнопку создать нельзя.

Кнопка авторизации в эбс лань[править]

Код кнопки:

Кнопка авторизации в эбс юрайт[править]

Код кнопки:

Кнопки авторизации на мобильных устройствах[править]

Если вы добавите кнопки в поле body в нодах типа subj (папки), то кнопки авторизации не будут видны в мобильном интерфейсе ELiS WebApps, т.к. в мобильном интерфейсе не отображаются аннотация (body).

Решить эту проблему можно путем создания отдельной страницы (например ноды типа ‘page’) и создания на одной странице сразу нескольких кнопок авторизации, просто повторив код для каждой ЭБС на одной странице.

Пользователям надо сообщить по сторонним каналам адрес этой страницы.

Построение архитектуры отказоустойчивого кластера keycloak

При использовании единого кластера для всех проектов возникают повышенные требования к решению для SSO. Когда количество проектов невелико эти требования не так ощутимы для всех проектов, однако с увеличением количества пользователей и интеграций повышаются требования к доступности и производительности.

Повышение рисков отказа единого SSO повышает требования к архитектуре решения и используемых методов резервирования компонентов и приводит к очень жесткому SLA. В связи с этим чаще при разработке или ранних стадиях внедрения решений проекты имеют собственную не отказоустойчивую инфраструктуру.

Для работы в режиме Active/Active и Active/Passive кластера требуется обеспечивать консистентность данных в реляционной базе данных — оба узла базы данных должны синхронно реплицироваться между различными геораспределенными ЦОД.

Самый простой пример отказоустойчивой инсталяции.

Какие преимущества дает использование единого кластера:

Права доступа

Права доступа выдаются клиенту в виде scope. Scope – это параметр, который состоит из разделённых пробелами строк — scope-token.

Каждый из scope-token представляет определённые права, выдающиеся клиенту. Например, scope-token doc_read может предоставлять доступ на чтение к какому-то документу на resource server, а employee — доступ к функционалу приложения только для работников фирмы. Итоговый scope может выглядеть так: email doc_read employee.

В OAuth 2.0 мы сами создаём scope-token, настраивая их под свои нужды. Имена scope-token ограничиваются только фантазией и двумя символами таблицы ASCII — ” и .

На этапе регистрации клиента, в настройках сервиса авторизации клиенту выдаётся стандартный scope по умолчанию. Но клиент может запросить у сервера авторизации scope, отличный от стандартного. В зависимости от политик на сервере авторизации и выбора владельца ресурса, итоговый набор scope может выглядеть совсем иначе.

Проблемы

Первая версия Auth — часть монолита. Он использует свой собственный протокол общения с сервисами. Такая «схема» была необходима в тот момент, но за несколько лет работы проявились проблемы.

Auth — часть монолита. Следовательно, сервис привязан к релизному циклу, что лишает возможности независимой разработки и деплоя. Кроме того, придется разворачивать весь монолит, если захотелось развернуть Auth, например, при масштабировании сервиса.

Dodo IS зависит от Auth. В старой реализации внешние сервисы обращаются к Auth при каждом действии пользователя, чтобы валидировать данные о нём. Настолько сильная привязка может привести к остановке работы всей Dodo IS, если Auth «приляжет» по какой-то причине.

Auth зависит от Redis. Притом достаточно сильно — неисправность работы Redis’а приведёт к падению Auth’а. Мы используем Azure Redis, для которого заявленный SLA 99,9%. Это значит, что сервис может быть недоступен до 44 минут в месяц. Такие простои не позволительны.

Текущая реализация Auth использует свой протокол аутентификации, не опираясь на стандарты. В большинстве своих сервисов мы используем C# (если говорим о backend) и у нас нет проблем с поддержкой библиотеки для нашего протокола. Но если вдруг появятся сервисы на Python, Go или Rust, разработка и поддержка библиотек под эти языки потребует дополнительных затрат времени и принесет дополнительные сложности.

Текущий Auth использует схему Roles Based Access Control, которая базируется на ролях. Обычно с ролью выдаётся полный доступ к определённому сервису, вместо привязки к конкретному функционалу. Например, в пиццериях есть заместители управляющего, которые могут вести определенные проекты: составлять графики или учитывать сырьё.

Проблемы подтолкнули к тому, чтобы спроектировать и написать новую версию Auth. На старте проекта мы потратили 3 недели только на изучение стандартов авторизации и аутентификации OAuth 2.0 и OpenID Connect 1.0. 

Примечание. Утрированно, статья — это пересказ RFC, который приходилось перечитывать несколько раз, чтобы понять, что происходит вокруг. Здесь я постарался уйти от этой сложности и рассказать всё максимально просто, структурировано, кратко и без описания сложных вещей, например, какие символы может содержать в себе ответ сервиса.

Распределенный кеш (infinspan)

Для корректной работы кластера требуется дополнительная синхронизация следующих типов кеша с использованием JBoss Data Grid:

Authentication sessions — используемый для сохранения данных при аутентификации конкретного пользователя. Запросы из этого кэша обычно включают только браузер и сервер Keycloak, а не приложение.

Action tokens — используются для сценариев, когда пользователю необходимо подтвердить действие асинхронно (по электронной почте). Например, во время потока forget password кэш actionTokens Infinispan используется для отслеживания метаданных о связанных маркерах действий, которые уже использовались, поэтому его нельзя использовать повторно.

Caching and invalidation of persistent data – используется для кэширования постоянных данных, чтобы избежать лишних запросов к базе данных. Когда какой-либо сервер Keycloak обновляет данные, все остальные серверы Keycloak во всех центрах обработки данных должны знать об этом.

Work — используется только для отправки сообщений о недействительности между узлами кластера и центрами обработки данных.

Регистрация клиента

Способ регистрации клиента, например, ручной или service discovery, вы выбираете сами, в зависимости от

фантазии

конкретной реализации. Но при любом способе при регистрации, кроме ID клиента, должны быть обязательно указаны 2 параметра: redirection URI и client type.

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

Client type — тип клиента, от которого зависит способ взаимодействия с ним. Тип клиента определяется его возможностью безопасно хранить свои учётные данные для авторизации — токен. Поэтому существует всего 2 типа клиентов:

Сервера приложений

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

На этом первая часть – теоретическая — закончена. В следующих циклах статей будут разобраны примеры интеграций с различными идентификационными провайдерами и примеры настроек.

Стандарт saml

Стандарт Security Assertion Markup Language (SAML) описывает способы взаимодействия и протоколы между identity provider и service provider для обмена данными аутентификации и авторизации посредством токенов. Изначально версии 1.0 и 1.1 были выпущены в 2002 – 2003 гг., в то время как версия 2.0, значительно расширяющая стандарт и обратно несовместимая, опубликована в 2005 г.

Этот основополагающий стандарт — достаточно сложный и поддерживает много различных сценариев интеграции систем. Основные «строительные блоки» стандарта:

Стандарты ws-trust и ws-federation

WS-Trust и WS-Federation входят в группу стандартов WS-*, описывающих SOAP/XML-веб сервисы. Эти стандарты разрабатываются группой компаний, куда входят Microsoft, IBM, VeriSign и другие. Наряду с SAML, эти стандарты достаточно сложные, используются преимущественно в корпоративных сценариях.

Стандарт WS-Trust описывает интерфейс сервиса авторизации, именуемого Secure Token Service (STS). Этот сервис работает по протоколу SOAP и поддерживает создание, обновление и аннулирование токенов. При этом стандарт допускает использование токенов различного формата, однако на практике в основном используются SAML-токены.

Стандарт WS-Federation касается механизмов взаимодействия сервисов между компаниями, в частности, протоколов обмена токенов. При этом WS-Federation расширяет функции и интерфейс сервиса STS, описанного в стандарте WS-Trust. Среди прочего, стандарт WS-Federation определяет:

Можно сказать, что WS-Federation позволяет решить те же задачи, что и SAML, однако их подходы и реализация в некоторой степени отличаются.

Типовые сценарии авторизации с использование oauth2 в keycloak

Authorization Code Flow

Токены

Токен в OAuth 2.0 — это строка, непрозрачная для клиента. Обычно строка выглядит как случайно сгенерированная — её формат не имеет значения для клиента. Токен — это ключ доступа к чему-либо, например, к защищённому ресурсу (access token) или к новому токену (refresh Token).

У каждого токена своё время жизни. Но у refresh token оно должно быть больше, т.к. он используется для получения access token. Например, если срок жизни access token около часа, то refresh token можно оставить жить на целую неделю. 

Refresh token опционален и доступен только для confedential клиентов. Пользуясь опциональностью токена, в некоторых реализациях время жизни access token сделано очень большим, а refresh token вообще не используется, чтобы не заморачиваться с обновлением.

За access token закреплён определённый набор прав доступа, который выдаётся клиенту во время авторизации. Давайте разберёмся, как выглядят права доступа в OAuth 2.0.

Форматы токенов

Существует несколько распространенных форматов токенов для веб-приложений:

Вместо вывода

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

Если хотите погрузиться в тематику детальнее, то рекомендую в RFC 6749 (для OAuth 2.0) и RFC 8628 (для Device Flow). Кроме того, следить за актуальными версиями RFC можно на ресурсе, посвящённому OAuth.

Если статья была полезна и захотите подробностей — пишите в комментариях, и в следующих статьях расскажу о PKCE, о протоколе аутентификации OpenID Connect 1.0, о нашей реализации сервера аутентификации и многом другом.

Полезные ссылки:

Заключение

В этой статье мы рассмотрели различные методы аутентификации в веб-приложениях. Ниже — таблица, которая резюмирует описанные способы и протоколы: