Identity server что это

Аутентификация и авторизация: сравниваем лучшие Identity-провайдеры для реализации Single Sign On

Привет! Я — Екатерина Срибна, .NET Developer в NIX. В IT я уже 3,5 года. Я Full Stack разработчик (Angular + .NET Core), поэтому подхожу к решению задач комплексно. В проектах могу заниматься разными задачами: анализировать требования, предлагать технические решения и участвовать в их реализации.

Сегодня большинство программных продуктов стараются предоставить пользователям уникальные возможности. Для этого надо идентифицировать юзеров и выдать им доступы. От разнообразия таких решений голова может пойти кругом даже у опытного специалиста. Поэтому я выбрала и сравнила самые популярные и гибкие готовые инструменты аутентификации и авторизации. Эти варианты помогут в реализации концепции Single Sign On (технологии единого входа).

Статья будет полезна и джунам, которые только знакомятся с темой, и тем, кто уже имеет опыт работы с аутентификацией и авторизацией. Материал больше ориентирован на .NET-разработчиков, но интересные инсайты для себя найдут и специалисты по Java и JavaScript.

Как работает технология единого входа

Технология единого входа (Single Sign On) значительно упрощает жизнь пользователей. Для перехода между разными сервисами, количество которых растет день ото дня, достаточно одной аутентификации и авторизации. Сложность только в том, что Identity-провайдеров, которые поддерживают Single Sign On, существует много. На старте может быть не понятно, какой провайдер лучше выбрать, как его использовать и настраивать у себя на проекте. Эта статья поможет вам во всем разобраться. Мы познакомимся с IdentityServer 4, рассмотрим Azure B2C и интегрируемся с Keycloak.

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

Под аутентификацией мы понимаем идентификацию пользователя, наличие у него идентификатора (логин, e-mail и т.п.), и при этом мы доверяем Identity-провайдеру, который выдал эту информацию. А уже чтобы пропустить пользователя, проверить его доступы, мы обращаемся к авторизации. Обычно этот механизм использует распределение скоупов и ролей для пользователей.

Благодаря технологии Single Sign On этот процесс упрощается. Пользователь может всего один раз авторизоваться и ходить между ресурсами без повторного введения своих кредов, вспоминая пароли. Проверка пользователя происходит «под капотом» системы.

Рассмотрим принцип Single Sign On на следующей схеме. Есть пользователь, есть его браузер, и пользователь взаимодействует с ним, чтобы постучаться на первый сайт. Также есть Identity-провайдер, который мы настроили. У сайта есть ключ, по которому он может валидировать всю информацию, получаемую от Identity-провайдера, с которым установлены доверительные отношения.

Пользователь отправляет запрос на получение данных какого-то ресурса, но этот ресурс требует авторизации. Далее сайт 1 с помощью пользовательского браузера через редирект отправляет запрос на Identity-провайдер, чтобы получить информацию о пользователе. Identity-провайдер смотрит, что у него нет никакой информации по этому запросу, он не знает, авторизован пользователь или нет, и выдает логин-страницу для него. Пользователь вводит свою информацию. Identity-провайдер ее валидирует и как бы говорит «О, все, привет! Я тебя вижу и знаю тебя», а затем отправляет токен обратно через пользовательский браузер редиректом на сайт. После валидации токена сайтом, выдаем пользователю ресурс и с ним — свои cookies. В будущем мы таким образом упростим взаимодействие нашего сайта и пользователя.

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

У этого подхода к аутентификации и авторизации есть два ключевых преимущества:

• Удобство для пользователя. Он один раз залогинился и получил доступ ко всем необходимым ресурсам без постоянных переходов по разным логин-страницам.
• Простота менеджмента. Мы со своей стороны можем централизованно управлять доступами. То есть в одном месте настраиваем пользователей, их доступы, роли, скоупы ресурсов и т.д. Это очень удобно для администрирования приложений.

Однако есть и существенный минус. Если учетные данные пользователя украли, то злоумышленник получит доступ ко всем ресурсам, к которым имела доступ эта учетная запись. Но я предлагаю посмотреть на ситуацию иначе. Любая система уязвима, потому что, будем честны, пользователи не заморачиваются, какой пароль выбрать. Если надо зарегистрироваться (особенно срочно), они выбирают какой-то плюс-минус легкий для запоминания пароль, к которому могут добавить пару символов. Я уж не говорю об использовании одного пароля для всех ресурсов. Поэтому риски надо учитывать — но и просто понимать, ради чего это нужно.

Основные способы реализации flow, которые поддерживает OAuth 2.0

Протоколов для настройки аутентификации и авторизации достаточно много: OpenID Connect, OAuth 2.0, SAML и WSFed. Я остановлюсь на первых двух.

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

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

Client Credentials Flow (он же Machine to Machine или Service to Service). С помощью этого flow можно настроить аутентификацию и авторизацию между несколькими сервисами. Причем не будет никакого взаимодействия с пользователем.

Device Authorization Flow. Подходит для приложений, которые должны работать еще на каком-то устройстве. То есть это не обязательно веб-приложение, а, например, приложение на Smart TV. В нем есть разные утилиты для просмотра онлайн-кинотеатров, видео на YouTube, торрент-видео и т.д. И почти все они сохраняют информацию о просмотрах пользователя и предлагают рекомендации, основываясь на опыте прошлых просмотров, что тоже требует авторизации.

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

Implicit Flow. Позволяет получать на клиентскую часть Access токен и Refresh токен. Этот механизм можно быстро реализовать, но его безопасность далека от максимальной.

Ситуацию можно описать так: мы отдаем на клиент наши токены и как бы говорим ему: «Храни наши токены, как хочешь, но мы будем ожидать, что ты будешь приходить к нам с конкретным токеном для получения информации». А потому нельзя быть уверенным в сохранности токенов. Такой flow стоит реализовывать, только если у вас защищенная сеть и нет утечек, когда злоумышленник попадает где-то на середине процессов.

Authorization Code Flow. Этот flow может быть альтернативой предыдущему, поскольку считается весьма безопасным. И хотя в нем клиентская часть знает Client ID и Client Secret, взаимодействие происходит уже с помощью Authorization-кода — это рандомно сгенерированный код. Обычно этот flow рекомендуют использовать для сервер-сайт приложений. Ярким примером является ASP.NET MVC приложение. Влезть в то, что генерируется сервером, сложно даже с какими-либо сторонними библиотеками.

Authorization Code Flow with Proof Key for Code Exchange (PKCE). Это усовершенствованный вариант прошлого flow. В нем происходит генерация еще двух рандомных кодов: Code Verifier и Code Challenge. На авторизацию мы идем с Code Challenge, после введения пользователем своих данных отдаем Authorization Code, за токеном мы идем с только что выданным Authorization Code и плюс с Code Verifier. В результате Identity-провайдер валидирует на основании трех кодов.

Если злоумышленник вытащит один код из системы, он ничего не сможет сделать с ним — нужны все три кода. Примерами, где можно задействовать такой flow, являются Single Page Applications: Angular приложения, React JS приложения, и нативные приложения под Android/iOS.

Hybrid Flow. Этот гибридный flow объединяет Implicit Flow и Authorization Code. Разработчики попытались усложнить его, чтобы сделать чуточку безопаснее, но он фактически содержит в себе плюсы и минусы обоих «прародителей».

Сравниваем три популярных Identity-провайдера

Далее рассмотрим готовые решения для использования в приложениях. Я бы выделила три: IdentityServer 4, Azure B2C и Keycloak.

IdentityServer 4

Этот провайдер поддерживает протоколы OpenID Connect и OAuth 2.0, а также внешние Identity-провайдеры. Можем подключить авторизацию с помощью Google, Facebook, Microsoft, Twitter, Instagram и т.д. Процесс установки и развертывания достаточно простой. Для этого надо создать приложение, установить Nuget-пакеты (IdentityServer4, IdentityServer4.EntityFramework, IdentityServer4.AspNetIdentity), а на клиентскую часть (если, например, MVC приложение в качестве клиента) — пакет IdentityModel. Он поможет нам получать «под капотом» информацию об Access токене и там же перенаправлять запросы, как нам нужно.

Преимуществами данного Identity-провайдера являются:

• Гибкость настройки и возможность вносить кастомные валидаторы. Так как мы сами создаем приложение и туда инсталим Nuget-пакеты, то можем сами же переопределить, допустим, валидацию токена, если решили, что нужна еще одна дополнительная проверка.
• Возможность создания UI. Мы можем создавать пользовательский интерфейс для страничек регистрации пользователей, логин-страниц, профиля пользователя и т.д. Существует реализация от создателей провайдера, но она подойдет не под любой случай. Поэтому сейчас IdentityServer 4 поставляется без пользовательского интерфейса, чтобы мы его не перекраивали, а просто сделали свой.
• Поддержка flow. Он работает со всевозможными flow, которые мы уже рассматривали (Auth Code, Device Flow и т.д.).
• Детализированная документация. У этого решения очень хорошая документация. Вы можете быстро разобраться со всем функционалом и подключить его. За такую документацию стоит благодарить обширное комьюнити.
• Бесплатно для коммерческого использования. Не думаю, что стоит как-то особо комментировать этот пункт. Здесь и так понятно преимущество.
• Подходит для CloudBase и On-Premise решений. Единственное, что стоит добавить к этому пункту: нам самим нужно позаботиться о том, как развернуть его в облаке.

Минусом же IdentityServer 4 является порог вхождения. Нужен уровень продвинутого пользователя, который достаточно хорошо разбирается в авторизации и аутентификации и понимает их механизмы. Второй отрицательный момент — нет административной панели, ее необходимо сделать самостоятельно. Придется проделать еще много работы, чтобы с нуля создать авторизацию и управлять всеми доступами в удобном виде. Это может вызвать вопросы у администратора, который будет просить привычный пользовательский интерфейс, чтобы все выбрать и сохранить.

Azure B2C

Этот Identity-провайдер поддерживает те же протоколы, что и IdentityServer 4, а также SAML и внешние провайдеры. По умолчанию у него предустановлены еще и пользовательские flow (Sign in, Sign up, Edit Profile, Password Reset), поддержка мультифакторной аутентификации и управление пользовательскими доступами.

Чтобы установить и настроить Azure B2C, потребуется подписка на Azure. Дальше мы создаем B2C Tenant ресурс, регистрируем API и клиентов с помощью App registrations. Чтобы все это подключить, понадобится один Nuget-пакет — Microsoft.Identity.Web, после чего у нас из кода все заведется.

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

Слева в меню мы видим меню Identity-провайдеров — здесь можно подключить внешние продукты. Есть меню пользователей и меню ролей с детальной статистикой. Мы можем увидеть, насколько часто юзеры логинятся в системе, увидеть их базовые цифры по взаимодействию с системой. И еще отмечу пункт User Flow. Я для примера выбрала парочку, которые созданы в несколько кликов — они предустановленные в Azure B2C. По итогу здесь нет никаких сложностей, когда нужно идти в какие-то конфиги, что-то настраивать и прописывать — с Azure B2C все легко и быстро.

У данного решения следующие плюсы:

• Легкость конфигурации базовых user flows.
• Cloud base решение.
• User management «из коробки».
• Кастомизируемый пользовательский интерфейс. Все странички и любая информация пользователей настраивается. Можно добавить свои стили, чтобы все выглядело цельно с вашей системой.
• Простота старта. Для начала работы нужно совсем немного кода. Все настраивается в несколько кликов на Azure-портале, затем происходит подключение в самом приложении — и все работает уже на базовом flow.

• Средний порог вхождения.

Несмотря на большое количество плюсов, есть у Azure B2C и минусы:

• Платное решение. Кроме подписки на Azure, следует упомянуть еще один финансовый момент. Если у нас в течение месяца более 50 тысяч активных пользователей, то за это придется доплачивать. Мультифакторная аутентификация тоже платная и со своими сроками использования.
• Сложность конфигурации flow. Для изменения даже базовых flow, например, добавления валидации или дополнительной информации, нужно создавать Custom Policy и много работать с конфигурационными XML и т.д.
• Не подойдет для On-Premise решений. Azure B2C разворачивают только в Cloud, а такие решения обычно даже устанавливаются и там, где может не быть доступа к интернету в принципе.

Keycloak

Поддерживает все те же протоколы, что и Azure B2C: OpenID Connect, OAuth 2.0 и SAML — как и тех же Identity-провайдеров. У него также есть предустановленные пользовательские flow и — что тоже важно — LDAP и Active Directory. С их помощью можно интегрировать пользователей из других систем. Также отмечу предустановленное управление пользователями и их доступами.

Сам Keycloak написан на Java. Но так как сейчас в основном используется кроссплатформенность, и .NET Core является ярким представителем таких технологий, почему бы не попробовать интегрироваться с другим языком программирования? Keycloak как сервис предоставляется с помощью разных площадок (Kubernetes, Podman, Openshift, Docker). Лично я работала из Docker. Там нет никаких сложностей: запускаешь одну команду, чтобы загрузить нужные пакеты, а затем все установилось и запустилось.

Чтобы базово настроить flow авторизации, нужно выполнить следующий сценарий:

1. Создать realm. Это точно такое же понятие, как и Tenant в Azure B2C, — то есть некая область или группа, в которые мы будем добавлять наше приложение в дальнейшем.
2. Добавить клиентов. Ими выступают наши приложения, которые должны быть в этой системе.
3. Добавить конфигурацию для этих приложений.
4. Создать скоупы.
5. Создать роли.

Ниже вы можете видеть админку Keycloak. В первую очередь здесь приводится список клиентов в системе. Базово для аккаунта у нас есть уже клиент, он создается как часть сервиса. Но я также создала и зарегистрировала свое демо-приложение.

После перехода в меню приложения перед вами открывается множество возможностей для его конфигурации. Здесь представлены Client-скоупы, то есть стандартные скоупы (тот же e-mail, профайл и роли), но можно добавить и свои и подключить их на приложения.

В меню слева также собрано много полезной информации: мы можем смотреть и роли, и Identity-провайдеров, и пользователей, и сессии.

Плюсы Keycloak:

• Гибкая настройка приложений и доступов к ним.
• Готовая административная панель. Keycloak предлагает различные конфигурации в пользовательском интерфейсе. Чтобы настроить доступы к приложениям, нам не нужно копаться в конфигурационных файлах, а достаточно выбрать нужные пункты и сохранить их. Это сможет сделать даже администратор приложения.
• Stand-alone приложение. Нам не надо заботиться, как его развернуть — все уже хостится само и полностью готово к работе.
• Подходит для Cloud и On-Premise решений.
• Бесплатное использование сервиса.

Среди минусов Keycloak:

• Высокий порог вхождения. Продвинутому пользователю с ним будет проще. Из-за обилия настроек надо детально разбираться, как это все скорректировать.
• Нет готовых официальных библиотек для .NET Core. Несмотря на это, мы можем из приложений интегрироваться с этим Identity-провайдером через тот же пакет Microsoft.AspNetCore.Authentication.JwtBearer. Он стандартно заложен в .NET Core.

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

• Все сервисы поддерживают примерно одни и те же протоколы.
• По стоимости проигрывает Azure B2C из-за оплаты подписки и пользовательской активности.
• По части .NET Core проигрывает Keycloak.
• Насчет менеджмента есть интересный нюанс. В IdentityServer 4 мы можем все реализовать из кода сами (управление ролями, где их передавать и в каком виде). В Azure B2C весь роль-менеджмент проходит через Access Policy. Но роль-менеджмент в Azure-портале распространяется только на сам портал, а не на приложения, которые мы добавляем. А вот Keycloak содержит плюсы обоих Identity-провайдеров. Он позволяет использовать keycloak-роли, чтобы дать юзеру доступ к страничке о пользователе, которая хостится самим Keyclock. В то же время мы можем добавлять роли на ресурсы и пользователям. Таким образом настройка ролей и их добавление происходит более гибко, и в результате роль можно получить из того же токена.
• По сложности настройки самый замысловатый Azure B2C. Если требуется какой-то базовый вариант, то все относительно нормально, на среднем уровне. Но чтобы что-то поменять, нужно сильно постараться.

В теме авторизации и аутентификации нельзя сказать: выбирайте только один flow, только один Identity-сервер или делайте только так. Более того, приведенные выше варианты — не единственные. Я советую сравнить разные готовые решения, взвесить их преимущества и недостатки и определить, что лучше всего подойдет именно в вашей ситуации.

Также делюсь полезными ссылками на официальную документацию перечисленных Identity-провайдеров:

�� Подобається Сподобалось 7

До обраного В обраному 8

Навигация

WSO2 Identity Server — решение для централизованного управления доступом к различным веб-приложениям, сервисам и API. WSO2 IS — первый продукт к области Enterprise identity Bus (EIB) реализующий интеграцию различных сервисов идентификации с использованием различных протоколов.

В дополнении к ролевой модели безопасности (RBAC — role based access control) WSO2 IS реализует тонкий policy-based контроль доступа, в то время как поддержка различных протоколов SSO (OpenID, SAML и прочее) c реализацией трансформации токенов безопасноти позволяет обеспечивать сквозную интеграция между различными системами, включая ведущими облачными сервисами: Google Apps и Microsoft Office 365.

Ключевые возможности WSO2 Identity Server

• API для интеграции с любыми приложениями;
• Многофакторная авторизация;
• Поддержка стандартов организации единой точки входа (SSO): OpenID, SAML2, Kerberos KDC;
• Сквозная авторизация межлу внутренними и облачными системами;
• Аудит через XDAS;
• Поддержка протоколов OAuth 1.0a, OAuth 2.0, WS-Trust, OpenID, SAML2, и WS-Trust STS;
• Интеграция с Microsoft SharePoint с поддержкой Passive STS;
• Поддержка «из коробки» Google Apps и Salesforce;
• Поддержка различных user store: встроенный LDAP, либо внешний LDAP, Microsoft Active Directory, Apache Cassandra или любая база данных;
• Поддержка XACML 2.0/3.0;

Скачать WSO2 Identity Server вы можете на странице продукта на сайте WSO2: http://wso2.com/identity-and-access-management/

По вопросам внедрения и сопровождения WSO2 Identity Server обращайтесь в компанию ЕМДЕВ.

Что вы можете сделать с WSO2 Identity Server?

Включить простой вход

Единая точка входа (SSO)

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

Связать все

Identity federation

Обеспечивает доступ к веб-приложениям и мобильным приложениям через несколько доверенных доменов с использованием открытых стандартов идентификации (включая SAML, OIDC и WS-Federation).

Обеспечьте безопасный доступ

Многофакторная и адаптивная авторизация

Многофакторная и адаптивная аутентификация на основе контекста, риска и аттрибутов идентичности.

Обеспечьте быстрый и удобный доступ

Аутентификация без пароля

Обеспечьте защиту от фишинга и доступ с помощью ключа безопасности или биометрических данных с поддержкой FIDO2.

Предоставьте пользователям расширенный контроль над своими данными

Конфиденциальность и управление согласием

Записывайте, просматривайте и отзывайте согласие пользователя, соблюдая принципы конфиденциальности в соответствии с принципами проектирования и отраслевыми стандартами и правилами (например, GDPR и CCPA). Предоставляет пользователям контроль над своими личными данными.

Получите единое представление об API

Безопасность API

Безопасный доступ к API и микросервисам на основе открытых стандартов, таких как OAuth.

Признание аналитиков

WSO2 IDENTITY SERVER Является лидером в The KuppingerCole Leadership Compass: CIAM platforms, 2020

WSO2 IDENTITY SERVER назван «A Strong Performer» в The Forrester WaveTM: Управление идентификацией клиентов и доступом, 4 квартал 2020 г.

Преимущества

Гибкий

Легкий и расширяемый для поддержки сложных сценариев использования IAM. Ускоряет вывод на рынок.

Открытый исходный код

Прозрачность, поддержка сообщества и доступ к полному коду продукта.

Открытые стандарты

Поддерживает все стандарты идентификации (OIDC, SAML, OAuth, FIDO2) для аутентификации и федерации в разнородных системах и протоколах.

API-driven

Широкий спектр API-интерфейсов, в том числе для идентификации, управления пользователями и авторизации, необходимых для решений CIAM.

Всесторонний

Единое решение, обеспечивающее ряд возможностей IAM.

Легкое развертывание

Разверните локально, в облаке или на гибридных архитектурах.

Общая стоимость

Прозрачная ценовая политика и гибкая коммерческая модель.

Масштабируемый

Крупнейший клиент управляет более чем 106 миллионами учетных записей!

Видео и другие материалы

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

Читать еще OK

Простые решения для сложных B2B-процессов

(с) ООО «ЕМДЕВ», 2005-

Заказать консультацию Заказать консультацию

197022, Санкт-Петербург,
ул. Профессора Попова, д. 23,
литера В, помещение 3Н
+7 (812) 385-57-78

IdentityServer4. Основные понятия. OpenID Connect, OAuth 2.0 и JWT

Этим постом я хочу открыть ветку статей посвященную IdentityServer4. Начнем мы с основных понятий.

Самым перспективным на текущий момент протоколом аутентификации является OpenID Connect, а протоколом авторизации (предоставления доступа) является OAuth 2.0. IdentityServer4 реализует эти два протокола. Он оптимизирован для решения типичных проблем безопасности.

OpenID Connect — это протокол и стандарт аутентификации, он не дает доступ к ресурсам (Web API), но т.к. он разработан поверх протокола авторизации OAuth 2.0, он позволяет получить параметры профиля пользователя как будто вы получили доступ к ресурсу UserInfo.

JWT (JSON Web Token) представляет собой веб-стандарт, который определяет способ передачи данных о пользователе в формате JSON в зашифрованном виде.

OAuth 2.0 (RFC 6749) — это протокол и стандарт авторизации. Он позволяет приложениям получить доступ к защищенным ресурсам, например к Web API.

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

1. Клиент запрашивает у пользователя разрешение пройти авторизацию от его имени. Клиент — это клиентское приложение обращающиеся к защищённым ресурсам от имени владельца ресурсов. Ресурс — это все наши защищенные сервисы Web API.
2. User разрешает клиентскому приложению пройти авторизацию от его имени, например, вводит логин и пароль. Логин и пароль будут являться грантом авторизации для клиентского приложения. User (владелец ресурса) — программа или человек, который может выдать доступ к защищённым ресурсам, например, путем ввода логина (username) и пароля (password);
3. Клиентское приложение запрашивает токен доступа у IdentityServer4 путём предоставления информации о самом себе ( client_id , client_secret ), предоставления разрешения на авторизацию от пользователя ( username , password ) и предоставления grant_type и scope . Затем сервер авторизации проверяет подлинность клиента и реквизиты владельца ресурса (логин и пароль).

Протокол OAuth 2.0 проводит аутентификации не только пользователя, но и клиентского приложения, осуществляющего доступ к ресурсам. Для этого протокол предусматривает такие параметры как client_id и client_secret.
сlient_id — это идентификатор клиентского приложения, используемый IdentityServer4 для поиска информации о клиенте.
client_secret является аналогом пароля для клиентского приложения и используется для аутентификации клиентского приложения на IdentityServer4 . Секрет клиента должен быть известен только приложению и API. Исходя из вышесказанного делаем вывод что IdentityServer4 должен знать о своих клиентах.

Типы токенов

Зарегистрированным в IdentityServer4 клиентам позволено запрашивать у IdentityServer4 identity -токен, access -токен и refresh -токен.

• identity-токен (токен идентификации) — результат процесса аутентификации. Содержит идентификатор пользователя и информации о том, как и когда пользователь проходит аутентификацию. Можно расширить своими данными.
• access-токен (токен доступа) — передается защищенному API и используется им для авторизации (разрешения доступа) к своим данным.
• refresh-токен (токен обновления) — необязательный параметр, который сервер авторизации может возвратить в ответ на запрос токена доступа.

Введем еще два понятия:

Authenticatation Server Url — конечная точка для получения ключа доступа. Все запросы на предоставление и возобновление ключей доступа будем направлять на этот URL-адрес.

Resource Url — URL-адрес защищенного ресурса, по которому нужно обращаться, чтобы получить доступ к нему, передавая ему ключ доступа в заголовке авторизации.

Запрос ключа доступа

Для запроса ключа доступа клиент делает POST запрос к конечной точке IdentityServer4 со следующим заголовком

'Content-Type': 'application/x-www-form-urlencoded', 'Accept': 'application/json', 'Expect': '100-continue'

и передавая следующие параметры:

'grant_type' : 'password', 'username' : login, 'password' : password, 'scope' : 'scope', 'client_id' : 'client_id', 'client_secret' : ''

username , password , client_id и client_secret были разобраны выше. Разберём остальные параметры:

grant_type — тип гранта или тип разрешения на авторизацию. Тип разрешения на авторизацию зависит от используемого приложением метода запроса авторизации, а также от того, какие типы разрешения поддерживаются со стороны API. В нашем случае он будет иметь значение password , что согласно спецификации OAuth 2.0 соответствует гранту реквизитов доступа владельца ресурса (авторизация по логину и паролю).

Протокол OAuth 2.0 определяет следующие типы грантов требующие обязательного взаимодействие с пользователям:

• код авторизации (authorization code). Является одним из наиболее распространённых типов разрешения на авторизацию, т.к. хорошо подходит для серверных приложений (server-side applications), где исходный код приложения и секрет клиента не доступны посторонним;
• неявный (implicit). Неявный тип разрешения на авторизацию используется мобильными и веб-приложениями, где конфиденциальность секрета клиента не может быть гарантирована;

И типы грантов, которые могут выполняться без интерактивного взаимодействия с пользователям:

• реквизиты владельца ресурса (resource owner). Этот тип разрешения стоит использовать только в том случае, когда клиентское приложение пользуется доверием пользователя и пользователь спокойно относится к вводу своего логина и пароля. Этот тип разрешения должен использоваться только в том случае, когда другие варианты не доступны. Данный тип разрешения удобен для корпоративных клиентов, которые в рамках своей системы уже использовали учетные данные пользователя и хотят перейти на OAuth 2.0 .
• учетные данные клиента. Используются при доступе приложения к API. Это может быть полезно, например, когда приложение хочет обновить собственную регистрационную информацию на сервисе или URI перенаправления, или же осуществлять доступ к другой информации, хранимой в аккаунте приложения на сервисе, через API сервиса.

scope — это необязательный параметр. Он определяет область видимости. Токен доступа, возвращенный сервером, будет обеспечивать доступ только к тем службам, которые входят в эту область. Т.е. мы можем несколько служб объединить под одним scope и если клиент получает ключ доступа к этому scope он получает доступ ко всем этим службам. Также scope может использоваться для ограничения прав авторизации (например, доступ на чтение или запись)

• .net core
• authentication
• authorization
• openid connect
• jwt
• архитектура по
• анализ и проектирование систем
• микросервисы
• identityserver4

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

Эта статья основана на моем опыте участия в одном из проектов.

Практичний курс від laba: Директор з продажу.
Створюйте та розвивайте успішний відділ продажів.

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

Авторизационный сервер, айдентити-сервер, аус-сервер — под этими понятиями обычно подразумевают software, который на основе юзер-логина и юзер-пароля выдает токен или что-то вроде авторизации в системе.

В этой статье вы можете заметить разные термины, но различий между ними нет.

Нам достался legacy-монолит…

Наша история выбора авторизационного сервера началась с работы над одним из древних проектов — legacy-монолита на .NET 3.5. Авторизация была выполнена в виде обычной страницы на ASP, где пользователь вводит логин и пароль. В code-behind была установлена ​​сессия, куда записывалась необходимая информация. Это была аутентификация и авторизация пользователя.

Ефективний курс від robotdreams: Software Architect.
Від ідеї до коду.

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

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

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

Новый порядок — переход к микросервисам

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

Фактически он и так был разделен, но одну часть мы вынесли как отдельный проект. Признаю, в этот момент об авторизации никто не думал. Мы скорее рассматривали новый проект как Proof of Concept. Нам хотелось попробовать сделать часть прежнего монолита на новых технологиях, с фронтендом, на современном фреймворке. Мы думали так: если идея сработает и все будут довольны, распространим этот подход и на другие части системы.

Для PoC-проекта мы придумали следующую схему. Есть фронтенд и гейтвей, под ним находится оркестратор, связанный с микросервисами. Программа получает запрос от фронтенда и на его основе делает запросы к соответствующим микросервисам:

Наша команда сделала фронтед на Angular, сервисы и оркестратор – на .NET 6, а также добавила API Gateway, работавшего как AuthGuard.

Ефективний курс від robotdreams: Software Architect.
Від ідеї до коду.

Если пользователь не авторизован, гейтвей не пропускает запрос и возвращает ошибку 401. При этом легаси оставался таким, как был. Мы не имели не то что возможности, а даже цели оверинженериты. Нам нужен был только PoC. Поэтому для авторизации мы использовали токен из легаси. Для этого добавили в проект новую функциональность. Она генерировала токен, а фронтенд забирал его и отправлял рекламировать с ним через API Gateway. Тот, в свою очередь, парсил токен для оценки валидности и пропускал запрос дальше. Эксперимент показал хорошие результаты. Мы постепенно перевели часть системы на микросервисы и это положительно оценили все стороны проекта.

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

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

Мы задумались о подготовке какого-то long-term-решения. Это позволило закрыть вопросы авторизации и аутентификации в системе, применить одинаковый подход на всех микросервисах и на всех текущих и будущих клиентах. Но переезд требовал инфраструктурных изменений. Потому стало понятно: качественная аутентификация и авторизация необходимы здесь и сейчас.

Всегда держите в голове базовые термины

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

• Аутентификация. Это процесс в системе, который должен найти ответ на вопрос «Кто ты?». В этот момент сервер распознает пользователя.
• Авторизация. Ее часто путают с аутентификацией, считая чуть ли не синонимом, но эти термины имеют разные значения. В этом случае система определяет, к каким ресурсам имеет доступ узнаваемый пользователь.
• OAuth 2.0 и OpenID Connect. Это протоколы и спецификации, говорящие о том, как правильно аутентифицировать и авторизовать пользователя.
• Grant Types. Часть протокола OAuth 2.0 . Показывает, что нужно сделать для получения аксес-токена: какие запросы отправить, куда, когда, к какой базе, какие должны быть респонсы запросов и т.д.
• Клиенты. Программы, которые дают запрос на защищенные данные. Чаще всего это фронтенд: мобильные приложения, веб-приложения, десктопные программы. Хотя клиентом может быть и бэкенд.

Експертний курс від robotdreams: Product Manager PRO.
Керуйте продуктом на високому рівні.

Grant Types

Отдельно хочу поговорить об этой части протокола OAuth. Существует несколько часто используемых грант-тайпов:

• Password Grant Type;
• Implicit Flow;
• Authorization Flow;
• Client Credentials.

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

Password Grant Type

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

Как происходит процесс получения токена в Password Grant Type? Представим пользователя, переходящего на клиента (допустим, фронтенд-приложение). На клиенте есть специальная страница, где пользователь вводит свои логин и пароль. После этого клиент посылает на айдентити-сервер следующую информацию: ClientSecret, ClientName, UserName и т.д. Сервер после сравнения данных возвращает аксесс-токен. Это легкий путь получения доступа, ведь нужны только настроенные на сервере ClientId и ClientSecret, полученные от пользователя UserName и UserPassword, а также Scopes — идентификаторы определения доступных пользователю данных.

Как видите, модель достаточно быстра для реализации. Благодаря этому в свое время Password Grant Type стандартизировал процесс получения аксес-токена. До этого можно наблюдать зоопарк различных механизмов того, как, где и почему использовать UserName и UserPassword. Иногда доходило до того, что логин и пароль отправлялись почти в незашифрованном виде в хедерах в реквест. Сегодня же Password Grant Type уже устарел. Его ключевой недостаток — пробелы в безопасности. Вы можете заметить, что в этой схеме клиент может где-то хранить логины и пароли. При этом эндпойнт из-за стандартизации грант-тайпа хорошо известен. Поэтому злоумышленники могут попытаться установить в систему NPM-пакет для сбора всех данных и перехватить выдаваемый токен.

Так преступник узнает, где находится сервис авторизации, а также узнает UserName и UserPassword. В результате система будет скомпрометирована. Более того: хакер будет постоянно получать валидный токен, потому что будет иметь логин и пароль. Также существует проблема хранения ClientId и ClientSecret на стороне клиента. Это не самое безопасное решение для фронтенда, поскольку здесь не осуществляется никаких редиректов. Привязка идет только на основе этих параметров. Если их украсть, новый клиент сможет подключить пользователя на сторонний сайт и ввести ClientId и ClientSecret. И тогда пользователи будут логиниться там и получать аксес-токен, который также будет угнан. Все это перечеркивает предыдущие преимущества Password Grant Type.

Implicit Flow

Этот подход более безопасен, поэтому некоторое время он был очень популярен. Implicit Flow достаточно удобен, его можно установить без особого труда. Однако у него есть несколько проблем с защищенностью, которые сегодня делают этот механизм в протоколе OAuth 2.0 нежелательным. Для понимания проблемы разберем флоу пошагово:

• Пользователь обращается к клиенту, фронтенд-приложению и нажимает кнопку «Логин».
• После этого клиент осуществляет пользовательский редирект на страницу /authorize на айдентити-сервер. Этот эндпойнт показывает пользователю свою страницу для ввода логина и пароля. Если они верны, аус-сервер выдает клиенту аксес-токен:

• На первый взгляд у Implicit Flow все хорошо. Здесь только одна логин-страница: мы сами ее написали, и наш сервер авторизации ответственен за нее. Для сравнения при наличии пяти клиентов в Password Grant Type требуется пять отдельных страниц для ввода логина и пароля. А здесь достаточно настроить редирект на единую логин-страницу для любого количества клиентов.

Но у этой схемы есть существенный недостаток. В Implicit Flow все построено на редиректах, то есть на GET-запросах. Поэтому на финальном шаге клиент получает аксес-токен из Query-параметров. Поэтому вредоносное программное обеспечение на клиенте может получить токен из кода так же, как мы это делаем с помощью библиотек для получения доступа к системе. А это уже очень серьезная проблема. Хотя гораздо хуже другое – риск похищения рефреш-токена. Аксесс-токен предоставляет доступ на 10 минут. Это много, но ограничивает злоумышленника, заставляя его повторять свои действия. С рефреш-токеном хакер свободен. Этот токен лишает пользователя необходимости повторного редиректа на айдентите сервер после окончания сессии.

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

Authorization Flow

Это рекомендованный OAuth-подход. Его сценарий сродни Implicit Flow: пользователь делает логин-клик на клиента и перенаправляется на /authorize на айдентите-сервер. Последний после подтверждения валидности логина и пароля возвращает не аксесс- и рефреш-токены, а авторизационный код в URL. Далее клиент отправляет на айдентити-сервер POST-запрос с ClientId, ClientSecret и Authorization Code и получает ответный POST-реквест с аксесс- и рефреш-токенами.

Из-за того, что такой реквест более защищен, чем Query-параметры, вся схема получается более надежной:

Есть идеальный флоу для получения аксес- и рефреш-токенов, но всегда есть «но».

Главный вопрос уже к команде, которая интегрируется с этим флоу: где хранить аксесс- и рефреш-токены?

Если в памяти, то при повторном входе нужно заново авторизироваться. А если положить токены в cookies, session или local storage, то вредоносное malware-ПО легко украдет их. В результате получение доступа устроено гораздо безопаснее, чем раньше, но хранение доступов уязвимо. Я думаю, многие сталкивались с этой проблемой. Каждый решает ее по-своему, потому дальше я расскажу, как мы решили этот вопрос.

Client Credentials

Раньше я описывал схемы получения доступа к API от клиента (web, desktop, mobile). Client Credentials необходим для доступа одной программы API к другой API.

Флоу организовано очень просто: приложение, запрашивающее доступ, отправляет ClientId и ClientSecret на айдентити-сервер, а после успешной проверки этих параметров возвращает аксесс-токен:

Такая простота возможна потому что при взаимодействии API не требуется интерактивность – ее практически некуда добавить. Апишки работают без фронтендов.

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

Выбор авторизационного сервера

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

• Keycloak;
• Cognito;
• Identity Server 4.

Каждый из них интересен по-своему.

Например, Identity Server 4 — это опенсорсный продукт, где можно легко настраивать разные моменты. Лично нашей команде он был хорошо знаком по предыдущим проектам.

Опенсорный сервер и Keycloak — один из самых популярных на сегодняшний день. Хотя мы были готовы к выбору платной программы, дающей все механизмы OAuth-протокола «из коробки». В этом случае нас заинтересовал Cognito , поскольку у нас была инфраструктура на AWS. При выборе сервера для нас важны были следующие параметры:

• возможности разнообразных флоу;
• поддержка SSO, Single Sign-On;
• хорошее соотношение цены и качества продукта;
• гибкие изменения и адаптации флоу под свои нужды;
• доступность использования кастомных решений;
• простой и удобный механизм для миграции пользователей.

Keycloak

К его преимуществам относятся простая и гибкая настройка, поддержка SSO и кастомных флоу и админпанель прямо «из коробки», что экономит много времени. Но как минимум для нашей команды, Keycloak имеет минусы:

1. Достаточно высокий порог вхождения. Если у вас есть схожий опыт работы с серверами, то будет проще. Но у нас такого специалиста не было.
2. С Keycloak нужно позаботиться о хостинге (хотя, да, это неудобство еще можно решить).
3. Source-code в Keycloak на Java. В нашем случае на проекте не было Java-разработчика.

При оценке этих характеристик мы помнили, что разрабатываем long-term support продукт. Если бы в дальнейшем возникли проблемы или нам просто было непонятно поведение системы, то пришлось бы что-то менять в коде. Это привело бы к серьезным проблемам и задержкам, поэтому мы отказались от Keycloak.

Cognito

У этого продукта много преимуществ. К примеру, это дешевое решение для нашего количества пользователей: активных и запланированных на будущее. Также у Cognito очень быстрый этап. Вы просто создаете User Pool и клиентов — и фронтенд-приложение фактически готово к авторизации. Сервер сразу можно использовать.

Но и у Cognito есть ряд недостатков, или, скорее, подозрений на недостатки.

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

Появились некие трудности при передвижении юзеров. Допустим, пользователь впервые входит в систему. Она перенаправляет его на страницу Cognito для ввода логина и пароля и проверяет, существует ли такой пользователь в пользовательском пуле. Его, конечно, нет, он ведь впервые здесь. Тогда на следующем этапе должна быть лямбда-функция, которая обращается к легаси-применению с введенными логином и паролем и проверяет их валидность. Если данные ошибочны, выдается Error. Если все правильно, то AWS, запомнив еще на первом этапе логин и пароль, создает пользователя в пользовательском пуле после подтверждения лямбда-функцией всех данных — и возвращает аксесс-токен:

Теперь представим, что пользователь снова входит в систему и вводит уже знакомые для AWS логин и пароль. AWS проверяет существование пользователя в пользовательском пуле (например, по мейлу), в случае положительного результата сверяет логин и пароль и при условии их правильности выдает аксесс-токен. Незамысловатая и эффективная схема.

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

Из-за всех этих недостатков мы решили не брать Cognito.

Identity Server 4

Наша команда уже имела опыт работы с Identity Server 4, то поначалу это могло показаться «тем самым» решением. Этот авторизационный сервер показал себя гибким, с простой интеграцией в .NET-приложение. Также к его безусловным достоинствам следует отнести наличие кастомных флоу, поддержку SSO и хорошую документацию. Здесь тоже нужно позаботиться о хостинге, но более серьезным недостатком является прекращение поддержки этого продукта после 22 ноября 2022 года. Учитывая долгосрочную перспективу развития нашего проекта, подобное ограничение было неприемлемым. Мы двинулись дальше.

Duende

Спасением для нас стал авторизационный сервер. Duende — это практически продолжение Identity Server 4 со всеми его преимуществами, но без проблем «22 ноября». Также есть BFF Security Framework. Подробную информацию о нем можете почитать на официальном сайте .

Я выделю самые интересные моменты:

• Нет токенов в браузере. Аксесс- и рефреш-токены полностью защищены от просмотра JS-кодом. Для этого к фронтенду добавляют бэкенд, создающий сессию и cookies. При этом бэкенды с фронтендом расположены на одном домене, поскольку первый является частью второго. В результате бэкенд может сетить куки под флагом HttpOnly. Далее они при каждом запросе фронтенда добавляются в реквест и идут на бэкенд, который проведет аутентификацию и авторизацию пользователя. Это заметно безопаснее генерации cookies с фронтенда, где их может перехватить «чужой» JS-код.
• Предоставление API для авторизационных эндпойнтов. В обычной схеме авторизации фронтенд посылает запрос с набором из ClientId, ClientSecret, с реквестами и добавлением OAuth, возвращает ответы с кодом типа 401 и т.д. Все это нам нужно тщательно выстраивать на клиенте. С помощью BFF Security Framework можно создать для фронтенда несколько эндпойнтов, допустим, BFF/Login. Как только фронтенд перейдет на него, фреймворк сам сделает все настройки для перередиректа на айдентите-сервере, авторизации и возвращения назад, обработки реквеста и сохранения аксесс- и рефреш-токенов в форме кук с флагом HttpOnly. Благодаря этому на стороне фронтенда можно вообще не беспокоиться о авторизации. Весь процесс автоматический: достаточно отправить BFF/Login или BFF/Logout с подставленной сессией для входа или выхода из системы.
• Управление сессиями. В BFF Security Framework есть отдельный модуль для тонкой настройки бэкенд-сессии. Это может пригодиться во многих ситуациях. К примеру, менеджмент сессий понадобится при очень больших cookies. Также он поможет для этапа Backchannel logout, когда пользователь распространяется с одной части системы или из всех.
• Менеджмент токенов. Этот фреймворк предоставляет множество API для управления и смены токенов. К примеру, можно получить аксесс-токен и при необходимости переработать или доработать его.
• Быстрая и легкая интеграция. BFF Security Framework это действительно не GET-пакет. Практически все предоставленные функциональности легко переопределяются. Например, можно кастомизировать эндпойнты для логина и логаута. Также можно хранить сессию как в MSSQL, так и сделать свое хранилище. То же касается и упомянутого токен-менеджмента.

Все это позволило нам принять правильное решение. Duende оказался оптимальным авторизационным сервером для наших задач.

Результат

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

При этом мы убрали API Getway и фронтенд общается непосредственно с оркестратором. К оркестратору мы добавили BFF Security Framework. Все хостится на одном домене — это требование BFF Security Framework. За счет этого токен предоставляется в оркестратор, что позволило построить еще и antiforgery-защиту фронтенда. Далее оркестратор аутентифицирует и авторизирует пользователя и отправляет рекламу на микросервис. Все просто и, что самое важное, надежно:

Если обобщить результаты всей нашей исследовательской и девелоперской работы, мы выиграли сразу в нескольких моментах:

• Вместо того чтобы придумывать велосипед с PoC и «кастомным» авторизационным сервером, который выдает токены, мы пришли к стандартизированному подходу для этой сферы. Поэтому сейчас наш продукт легко интегрирован с другими решениями.
• Используем одинаковый подход для разных клиентских приложений. После настройки флоу для первого клиента добавлять 2, 3, 5, 10 и все остальные уже не будет проблемой. За счет этого сокращается время интеграции новых клиентов.
• Есть актуальный рекомендованный OAuth-протоколом принцип Authorization Grant Type.
• В нашем случае BFF Security Framework показал себя хорошим решением, которое на сегодняшний день покрывает все наши потребности и экономит время. С ним мы больше не храним аксесс- и рефреш-токены в браузере. Используем практически весь его функционал: у нас есть и Backchannel logout, и бэкенд-сессия. Авторизацию и аутентификацию убрали с фронтенда.

Конечно, в вашем случае все может сложиться иначе, и вы выберите, скажем, Keycloak. Более того, если вам не нужны дополнительные механизмы редиректов и вообще нет сложной логики, тогда и Cognito или Azure Active Directory отлично подойдут. Поэтому при выборе айдентити-сервера, прежде всего, советую грамотно оценивать свои задачи и возможности каждого существующего авторизационного сервера.

Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.