Как работает система единого входа (SSO) Описание в комментариях 👇
Как работает система единого входа (SSO) Описание в комментариях 👇
182
👍 45
1
Комментарии (1)
Channel_Bot
Единый вход (SSO) делает доступ максимально лёгким. Один вход — и вы уже внутри Slack и нескольких внутренних инструментов, не входя в систему снова.
Но за одним входом происходит много всего.
Шаг 1: Первый вход
- Пользователь открывает приложение, например Salesforce.
- Вместо прямого запроса учетных данных Salesforce перенаправляет браузер на провайдера идентификации (IdP), такого как Okta или Auth0. Это перенаправление обычно происходит через ответ HTTP 302.
- Затем браузер отправляет запрос на аутентификацию IdP с помощью протоколов, таких как SAML или OpenID Connect (OIDC).
- IdP представляет страницу входа. Пользователь вводит свои учетные данные, иногда вместе с MFA.
- После проверки IdP создаёт сессию входа и отправляет ответ на аутентификацию (утверждение SAML или ID-токен) через браузер.
- Браузер пересылает этот ответ обратно в Salesforce.
- Salesforce проверяет токен и создаёт собственную локальную сессию, обычно хранящуюся в виде cookie, и предоставляет доступ.
Шаг 2: Магия SSO
- Теперь пользователь открывает другое приложение, например, Slack.
- Slack также перенаправляет браузер на тот же идентификатор. Но IdP проверяет и видит, что у пользователя уже есть активная сессия. Таким образом, этап входа полностью пропускает и выдает новый токен аутентификации.
- Браузер пересылает этот токен в Slack.
- Slack проверяет его, создаёт собственный сессионный cookie и предоставляет доступ.
Ключевая идея SSO проста. Приложения сами не аутентифицируют пользователей. Они полагаются на центрального поставщика идентификации для проверки пользователя и выдачи токена, которому доверяют другие системы.
Комментарии (1)
Но за одним входом происходит много всего.
Шаг 1: Первый вход
- Пользователь открывает приложение, например Salesforce.
- Вместо прямого запроса учетных данных Salesforce перенаправляет браузер на провайдера идентификации (IdP), такого как Okta или Auth0. Это перенаправление обычно происходит через ответ HTTP 302.
- Затем браузер отправляет запрос на аутентификацию IdP с помощью протоколов, таких как SAML или OpenID Connect (OIDC).
- IdP представляет страницу входа. Пользователь вводит свои учетные данные, иногда вместе с MFA.
- После проверки IdP создаёт сессию входа и отправляет ответ на аутентификацию (утверждение SAML или ID-токен) через браузер.
- Браузер пересылает этот ответ обратно в Salesforce.
- Salesforce проверяет токен и создаёт собственную локальную сессию, обычно хранящуюся в виде cookie, и предоставляет доступ.
Шаг 2: Магия SSO
- Теперь пользователь открывает другое приложение, например, Slack.
- Slack также перенаправляет браузер на тот же идентификатор. Но IdP проверяет и видит, что у пользователя уже есть активная сессия. Таким образом, этап входа полностью пропускает и выдает новый токен аутентификации.
- Браузер пересылает этот токен в Slack.
- Slack проверяет его, создаёт собственный сессионный cookie и предоставляет доступ.
Ключевая идея SSO проста. Приложения сами не аутентифицируют пользователей. Они полагаются на центрального поставщика идентификации для проверки пользователя и выдачи токена, которому доверяют другие системы.