+7 (495) 801-60-42

SSO, OAuth2 и OpenID Connect: простое объяснение

В этой статье простым языком объясняем: sso что это, как с ним связаны OAuth2 и OpenID Connect, где их применять на сайте и в мобильном приложении, чем они отличаются от SAML и что важно для безопасности и интеграций с CRM и B2B‑порталами.

SSO что это: простое объяснение

SSO (Single Sign‑On) — это единая авторизация, когда пользователь один раз входит в систему и получает доступ к нескольким сайтам, приложениям или внутренним сервисам без повторного ввода логина и пароля. SSO не «придумывает» новый способ проверки личности — это архитектура поверх протоколов аутентификации/авторизации, которая переносит доверие между системами. На практике SSO строят на базе SAML 2.0 или пары OAuth2 + OpenID Connect (OIDC), иногда с корпоративными провайдерами (Azure AD, Keycloak, Okta, Auth0, отечественные IdP).

Ключевые выгоды:

  • меньше трения для пользователя: единый вход в веб и мобильные клиенты;
  • централизованная безопасность и управление доступами;
  • снижение затрат поддержки (меньше забытых паролей, унификация MFA);
  • единая точка аудита и логирования.

OAuth2: что это простыми словами

OAuth 2.0 — это протокол авторизации (не аутентификации). Его задача — выдать приложению ограниченный доступ к ресурсу от имени пользователя без передачи пароля приложению. Доступ выражается «токенами доступа» (access token), которые клиент отправляет в API.

Базовые роли:

  • Resource Owner — пользователь;
  • Client — приложение (ваш сайт, SPA, мобильное приложение);
  • Authorization Server — сервер авторизации (IdP), который выдает токены;
  • Resource Server — API, которое проверяет токены и отдает данные.

Популярные флоу:

  • Authorization Code + PKCE — современный стандарт для браузерных SPA и мобильных приложений. Безопаснее, чем implicit.
  • Client Credentials — сервер‑к‑серверу, без пользователя (для внутренних сервисов, крон‑задач, бэкендов).
  • Device Code — для устройств без браузера (смарт‑ТВ, терминалы).

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

OpenID Connect: как работает поверх OAuth2

OpenID Connect (OIDC) — это надстройка над OAuth2 для аутентификации. OIDC добавляет ID Token — компактный объект с утверждениями (claims) о пользователе: идентификатор (sub), время выдачи, срок жизни, аудиторию (aud), Issuer (iss), а также профильные поля (email, name и др.). ID Token обычно представляет собой JWT и подписывается провайдером (JWS) — клиент может проверить подпись и быть уверен, что данные не подменены.

Основные элементы OIDC:

  • Discovery (/.well-known/openid-configuration) — автоматическая конфигурация эндпоинтов и ключей;
  • Scopes (openid, profile, email и т. д.) — Какие данные о пользователе запрашиваем;
  • Claims — конкретные поля профиля в ID Token или по UserInfo endpoint;
  • PKCE — обязательный атрибут безопасности для публичных клиентов (SPA, мобильные);
  • Refresh Token Rotation — безопасное продление с ротацией рефреш‑токена.

Результат: клиент надежно узнает «кто пользователь» (аутентификация) и получает access token для доступа к API (авторизация).

JWT токен: что это и зачем нужен

JWT (JSON Web Token) — компактный формат токенов в виде трёх частей Base64url: заголовок, полезная нагрузка (claims), подпись. Преимущества:

  • самодостаточность: не всегда нужен запрос к БД, чтобы проверить токен;
  • стандартные поля (iss, sub, aud, exp, iat, nbf) и настраиваемые claims;
  • подпись (JWS) или шифрование (JWE).

Практические советы:

  • короткий TTL для access token (5–15 минут) + refresh token для продления;
  • audience и issuer должны строго проверяться API;
  • используйте ключевую ротацию (JWKS, kid) и алгоритмы не ниже RS256/ES256;
  • не складывайте чувствительные данные в JWT: токен читается любым, у кого он есть.

SAML vs OpenID Connect: что выбрать

SAML 2.0 исторически популярен в корпоративном мире (B2B, SSO между доменами, интеграции с «тяжелыми» IdP). Он основан на XML, использует браузерные редиректы и подписи XML. OpenID Connect современнее: JSON, JWT, лучше дружит с мобильными и SPA, проще для микросервисной архитектуры и API‑шлюзов.

Рекомендации по выбору:

  • Если у партнеров/заказчика корпоративный IdP, требующий SAML, или есть устоявшиеся федерации — берите SAML.
  • Если вы строите продукт с мобильными клиентами, SPA и публичным API — OIDC предпочтительнее.
  • Гибрид возможен: внешний периметр — OIDC, для части B2B‑интеграций — SAML через шлюз/брокер (например, Keycloak, Authentik, Azure AD).

SSO на сайте и в приложении: схемы и практики

Веб‑приложение (SPA + API):

  • Используйте Authorization Code + PKCE.
  • ID Token — только для фронта; доступ к данным — через access token в API.
  • Access token храните в памяти (in‑memory). Для сессии используйте защищенную httpOnly‑cookie с серверной сессией или обменом кода на токены на бэкенде (Backend for Frontend, BFF‑паттерн) для снижения рисков XSS.

Мобильное приложение:

  • Тот же Authorization Code + PKCE через системный браузер/ASWebAuthenticationSession/Custom Tabs для безопасной сингл‑сайн‑он с другими приложениями.
  • Храните рефреш‑токен в защищенном хранилище (Keychain/Keystore). Включите ротацию рефреша.

Микросервисы и внутренние API:

  • Для межсервисных вызовов — Client Credentials со строго определенным aud и кратким TTL.
  • Рассмотрите мидлварь в API‑шлюзе (Kong, NGINX, Envoy) для централизованной валидации токенов.

Управление сессиями и выходом:

  • Single Logout (SLO) в SAML/OIDC помогает разлогинить пользователя во всех клиентах.
  • Применяйте back‑channel logout или токен‑ревокацию для управляемого завершения сессий.

Интеграция: CRM, B2B‑порталы и инфраструктура

CRM и внешние системы:

  • SSO интеграция с CRM упрощает доступ менеджеров и партнеров: единый вход в CRM, сайт и партнерский портал. При OIDC используйте SCIM/Just‑In‑Time Provisioning для синхронизации аккаунтов.
  • Для гранулярных прав в CRM и порталах применяйте role/permissions claims в access token (или храните роли на стороне API и включайте только идентификатор в токен).

B2B‑порталы:

  • SSO для B2B портала снижает количество учеток и упрощает онбординг партнеров. Часто требуется федерация с IdP клиента (SAML или OIDC). Заранее согласуйте домены, атрибуты и политику MFA.

Инфраструктура и эксплуатация:

  • Централизованный IdP, мониторинг health эндпоинтов (authorize, token, jwks), алерты по отказам и аномалиям входа.
  • Вынос секретов в менеджеры секретов, ограничение исходящих IP для токен‑эндпоинта, защита rate limit и bot‑defense.

Где мы помогаем:

  • Проектируем архитектуру SSO для веба и мобильных клиентов, реализуем OIDC‑флоу и интеграции с IdP в рамках услуг
    .
  • Строим безопасные B2C/B2B‑кабинеты с единым входом и ролевой моделью — услуга
    .
  • Настраиваем CI/CD, секреты, прокси‑шлюзы, балансировку и логи аудита — услуга
    .

По теме инфраструктуры также может быть полезно: Kubernetes: что это и когда он нужен проекту и Обслуживание серверов для веб‑приложений: что это и зачем бизнесу.

Безопасная аутентификация: риски и меры

Типовые риски:

  • Перехват токенов через XSS/магнит‑расширения браузера;
  • Replay‑атаки при утечке refresh token;
  • Недостаточная проверка aud/iss/exp и использование слабых алгоритмов подписи;
  • Отсутствие MFA и детекции аномалий входа;
  • Смешение аутентификации и авторизации в бизнес‑логике.

Что делать:

  • PKCE повсеместно для публичных клиентов; отключить implicit flow.
  • Короткий срок жизни access token, ротация refresh token, серверная ревокация.
  • BFF‑паттерн или httpOnly‑cookies для фронта; хранение токенов не в LocalStorage.
  • Обязательная проверка подписи (JWS), iss/aud/exp/nbf, clock skew.
  • MFA (TOTP/WebAuthn), адаптивная аутентификация и риск‑скоринг.
  • Логи аудита входов, алерты по гео/устройствам, защита от брутфорса.
  • Регулярная ротация ключей (JWKS), минимизация прав (scopes, least privilege).

Чек‑лист внедрения SSO/OAuth2/OIDC

  • Определите юзкейсы: веб, мобильное, API, B2B‑портал, CRM.
  • Выберите провайдера IdP (Azure AD/Keycloak/Okta/другое) и протокол (OIDC/SAML).
  • Спроектируйте потоки: Authorization Code + PKCE, Client Credentials, Device Code.
  • Настройте Discovery, scopes и claims; определите роли/разрешения.
  • Реализуйте хранение и ротацию токенов; проверьте revocation/logout.
  • Включите MFA и политики паролей; настройте риск‑скоринг.
  • Добавьте BFF или httpOnly‑cookies для фронтенда; запретите implicit.
  • Валидация JWT: подпись, iss, aud, exp, nbf, kid, ключевая ротация.
  • Логи аудита, мониторинг IdP, rate limiting и защита ботов.
  • Проведите security‑тесты: XSS, CSRF, SSRF, защита редиректов и callback‑URL.
  • Задокументируйте процессы онбординга и выхода пользователей (SLO, deprovisioning).

Итоги

SSO — это единая точка входа, которая делает опыт пользователя проще и повышает управляемость доступа. OAuth2 отвечает за выдачу ограниченных прав приложениям, а OpenID Connect добавляет подтвержденную информацию о личности. Для сайтов, мобильных приложений и B2B‑порталов это стандарт современной безопасности. Если вам нужен разбор архитектуры, подбор IdP и внедрение под ваш стек — обращайтесь: мы поможем спроектировать и реализовать решение без «магии», с прозрачными процессами и документацией.

Другие полезные статьи

Делимся экспертизой, разбираем кейсы и рассказываем, как превращать идеи в работающие digital-продукты