Перейти к содержанию

Настраиваем поставщика единого входа

Единый вход (Single Sign-On) — Это система, в которой различные приложения могут переиспользовать аутентификационные данные. Обычно в этой системе существует единое приложение, которое управляет аутентификацией пользователя. Такое приложение называется поставщиком единого входа (SSO provider). После того, как пользователь аутентифицировался в одном приложении системы, он автоматически становится аутентифицированным во всех приложениях системы.
Существует много различных поставщиков SSO: Keycloak, Octa, Microsoft Azure Active Directory и множество других. Крупные технологические компании используют свои собственные поставщики, что позволяет, к примеру, залогиниться на сайте, на котором вы раньше никогда не были при помощи аккаунта Google или Facebook.
Большая часть подобных систем используют стандартизованные протоколы аутентификации и авторизации, а именно — комбинацию из протоколов OpenId Connect и OAuth.

Обзор OpenID Connect и OAuth

OpenId Connect — это протокол, специально разработанный для аутентификации, тогда как OAuth 2.0 — это протокол авторизации. Комбинируются они следующим образом: OpenID Connect определяет процесс входа, а OAuth определяет структуру аутентификационного токена, которая позволит определить, имеет ли пользователь требуемые для доступа к конкретному ресурсу разрешения.
OpenID Connect определяет несколько различных способов аутентификации (authentication flows), но их общие принципы сводятся к следующему:

  1. Пользователь открывает приложение и инициирует процедуру входа;
  2. Приложение редиректит его на страницу аутентификации приложения SSO;
  3. Если пользователь вводит верные аутентификационные данные (credentials), приложение SSO генерирует временный код;
  4. Приложение SSO редиректит пользователя обратно на исходное приложение и передаёт ему сгенерированный код;
  5. Код отправляется обратно провайдеру SSO, и если коды совпадают, провайдер передаёт исходному приложению токен аутентификации;
  6. Токен можно сохранить в куку, таким образом приложение знает, что пользователь аутентифицирован.

Обратите внимание, что в данной схеме исходное приложение не имеет никакого представления о пользовательских аутентификационных данных, их вводят на сайте SSO. Исходное приложение только передаёт адрес, на который нужно вернуть пользователя при успешной аутентификации.
Аутентификационный токен, получаемый от провайдера SSO, обычно строится в формате JSON Web Token.

Сперва добавим проект поставщика SSO в наше решение и настроим его для работы с нашим приложением.

Настраиваем IdentityServer 4

Конфигурируем приложение SSO

Последнее обновление : 6 сентября 2023 г.
Дата создания : 26 февраля 2023 г.

Комментарии

Комментарии