OpenID Connect и SSO в Azure AD

Логотип Microsoft Azure

Быстрые ссылки

Что такое OpenID Connect?
Как добавить приложение OpenID в Azure AD?
Как работает аутентификация с OpenID Connect
Включение механизма согласия (Consent Framework)
Роли и чеклисты
Безопасность и требования к приёмке
Заключение

Что такое OpenID Connect?

OpenID Connect (OIDC) — это слой аутентификации поверх OAuth 2.0, который возвращает информацию о пользователе (id_token) и даёт стандартный способ единого входа (SSO). Коротко:

id_token — JWT, удостоверяющий личность пользователя.
access_token — токен доступа для вызовов API.
refresh_token — обновляет access_token без повторного входа.

Ключевые преимущества OIDC для корпоративных сред:

Хорошо подходит для мобильных и SPA‑клиентов.
Основан на знакомом разработчикам OAuth 2.0.
Удобен для внешних партнёров и SaaS‑интеграций.
Широко поддерживается: Azure AD, Okta, Google, Auth0 и др.

Отличия от SAML:

SAML исторически ориентирован на корпоративные web‑приложения и федерацию.
OIDC — современный REST‑ориентированный протокол с JSON и JWT, удобен для мобильных/SPA.

Важно: OIDC и SAML могут сосуществовать; выбор зависит от архитектуры, клиентов и требований к совместимости.

Как добавить приложение OpenID в Azure AD

Ниже — пошаговая инструкция для администратора и разработчика.

Войдите в Azure Portal и откройте “Azure Active Directory”.
В меню выберите “Enterprise applications” → “All applications”.
Нажмите “New application” и найдите нужный коннектор/приложение по имени. Если кнопка “Add” отключена, администратор арендатора должен нажать “Sign up” и предоставить доступ приложению.

Экран регистрации нового приложения в Azure Active Directory

После авторизации примите запрошенные разрешения. Откроется домашняя страница приложения в портале.
Перейдите в “App registrations” (Регистрация приложений), откройте своё приложение и настройте:
- Redirect URI (URI ответа) — URL, на который будет перенаправление после входа.
- Типы клиетов — Web, SPA, Native (mobile).
- Параметры сертификатов и секретов (Client secret) для backend‑приложений.
Ограничение: в пределах одного арендатора можно зарегистрировать только один экземпляр (one app instance per tenant). Повторная попытка добавить ту же интеграцию приведёт к отказу.

Полезные подсказки:

Используйте отдельные регистрации для production и staging/qa с разными Redirect URI.
Для публичных клиентских приложений избегайте Client Secret; применяйте PKCE.
Документируйте все Redirect URI и гарантируйте, что они указаны с точным протоколом и путём.

Как работает аутентификация с OpenID Connect

Общий поток аутентификации (авторизация кода) выглядит так:

Клиент инициирует запрос на /oauth2/authorize с параметрами: client_id, redirect_uri, response_type=code, scope=openid profile email, state, nonce (и code_challenge для PKCE).
Пользователь вводит учётные данные и даёт согласие на разрешения (если требуется).
Azure AD возвращает authorization_code в перенаправлении на redirect_uri.
Клиент отправляет authorization_code на /oauth2/token с client_secret (для конфиденциальных клиентов) или с PKCE verifier.
Сервер авторизации возвращает id_token, access_token (и опционально refresh_token).
Клиент валидирует id_token: подпись, issuer (iss), audience (aud), exp, nonce.
Клиент устанавливает сессию (cookie) или хранит токены в безопасном хранилище.
При вызовах защищённого Web API клиент передаёт access_token в заголовке Authorization: Bearer .
Web API валидирует access_token и возвращает защищённые ресурсы.

Пример запроса авторизации (схема GET-запроса):

GET https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
  client_id=YOUR_CLIENT_ID
  &response_type=code
  &redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
  &response_mode=query
  &scope=openid%20profile%20email%20offline_access
  &state=12345
  &nonce=67890
  &code_challenge=CODE_CHALLENGE
  &code_challenge_method=S256

Mermaid‑схема (упрощённый поток):

sequenceDiagram
  participant User
  participant Browser
  participant ClientApp
  participant AzureAD
  participant WebAPI

  User->>Browser: Открывает ClientApp
  Browser->>ClientApp: Перенаправление на Azure AD '/authorize'
  ClientApp->>AzureAD: Запрос авторизации
  AzureAD-->>User: Просит логин/согласие
  User-->>AzureAD: Вводит данные
  AzureAD-->>Browser: Redirect с code
  Browser-->>ClientApp: code
  ClientApp->>AzureAD: Обмен code на token '/token'
  AzureAD-->>ClientApp: id_token, access_token, refresh_token
  ClientApp->>WebAPI: Запрос с access_token
  WebAPI->>ClientApp: Защищённые данные

Ключевые моменты валидации:

Всегда проверяйте подпись JWT и поля iss, aud, exp и nonce.
Для SPA и нативных клиентов используйте PKCE.
Не храните long‑lived refresh_token в небезопасном месте.

Включение механизма согласия (Consent Framework)

Consent framework в Azure AD определяет, какие разрешения (scopes) приложение запрашивает и кто может дать на них согласие — пользователь или администратор арендатора.

Как настроить разрешения API:

В App registrations откройте приложение → “API permissions”.
Нажмите “Add a permission” → выберите Microsoft Graph или другой API.
Выберите тип разрешения: Delegated permissions (от имени пользователя) или Application permissions (от имени приложения).

Путь доступа: Регистрация приложения → API Permissions → Add a permission

Поведение при входе:

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

Окно согласия с перечислением запрашиваемых разрешений

Подсказки:

Для многоарендных (multitenant) приложений используйте явный процесс admin consent, чтобы администратор мог централизованно одобрить доступ для всех пользователей своего арендатора.
Документируйте, какие именно разрешения запрашивает приложение, и почему они нужны.

Когда OIDC не подходит — примеры и ограничения

Интеграция со старыми корпоративными приложениями, которые поддерживают только SAML: в таких случаях SAML остаётся предпочтительным.
Если требуется обмен утверждениями (assertions) в нестандартном формате, которого нет в OIDC.
Когда инфраструктура полностью отключена от интернета и не допускает внешних HTTP‑перенаправлений.

Контрпример: если у вас есть legacy‑фреймворк, который поддерживает только SAML 1.1 и использует SOAP‑процессы, внедрение OIDC потребует значительной переработки сервиса и фронтенда.

Альтернативные подходы

SAML 2.0 — зрелый стандарт для корпоративной федерации.
WS‑Federation — поддерживается в некоторых Microsoft‑ориентированных сценариях.
Reverse proxy с интегрированной аутентификацией — для приложений, где изменить код нельзя.
OIDC gateway — если нужно унифицировать множество провайдеров под единый интерфейс.

Выбор зависит от типов клиентов, требуемых сертификатов, поддержки браузеров и мобильных устройств.

Роли и чеклисты

Администратор арендатора:

Зарегистрировать приложение в Azure AD или одобрить sign‑up.
Проверить и одобрить разрешения Microsoft Graph при необходимости.
Настроить политики Conditional Access, MFA для чувствительных приложений.
Настроить аудит и логирование входов.

Разработчик приложения:

Настроить Redirect URI и Response Type.
Реализовать обмен authorization_code на token.
Валидировать id_token и проверять nonce.
Реализовать PKCE для публичных клиентов.
Обеспечить безопасное хранение refresh_token.

Команда безопасности:

Установить политику жизни токенов и ротации секретов.
Настроить SSO logout и обработку token revocation.
Включить мониторинг необычной активности и SIEM‑сбор.

Мини‑методология внедрения (быстрая дорожная карта)

Проанализируйте архитектуру: типы клиентов (web, SPA, mobile), требуемые API.
Выберите модель авторизации: Authorization Code Flow (+ PKCE) для SPA/mobile; Authorization Code с client_secret для backend.
Зарегистрируйте приложение в Azure AD, настройте Redirect URI и Reply URLs.
Настройте API permissions и проведите тестовый admin consent в тестовом арендаторе.
Реализуйте обработку токенов и проверку JWT.
Проведите тесты: вход, отказ в доступе, обновление токена, выход.
Выпустите в продакшен и включите мониторинг.

Критерии приёмки

Успешная аутентификация пользователей и получение валидного id_token.
Web API принимает access_token и возвращает защищённые данные.
PKCE корректно работает для публичных клиентов.
Администратор может централизовано отозвать согласие и доступ.
Логи доступа доступны в SIEM, настроены предупреждения на аномалии.

Безопасность и конфиденциальность

Рекомендации по усилению безопасности:

Используйте PKCE для всех публичных клиентов (SPA, мобильные приложения).
Устанавливайте короткий срок действия access_token и включайте refresh_token rotation.
Храните client_secret и refresh_token в защищённых секретных хранилищах (Key Vault, HSM).
Реализуйте проверку nonce и state для защиты от CSRF и replay‑атак.
Настройте Conditional Access: требуйте MFA для критичных операций и внешних сетей.
Обеспечьте корректный logout (front‑channel и back‑channel) и обработку Revocation Endpoint.

Конфиденциальность и соответствие GDPR:

Запрашивайте минимально необходимые разрешения (data minimization).
Ясно указывайте в политике приватности, какие данные и для каких целей приложение получает через Microsoft Graph.
Обеспечьте возможность удаления привязки аккаунта и отзыва согласия пользователем или администратором.

Примеры конфигурации и сниппеты

Пример валидации id_token (псевдокод):

// Проверить подпись (JWK set) и стандартные поля
token = decodeJWT(id_token)
if token.iss != expectedIssuer: reject
if expectedAudience not in token.aud: reject
if token.exp < now: reject
if token.nonce != savedNonce: reject

Пример параметров при запросе /token:

POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
Headers: Content-Type: application/x-www-form-urlencoded
Body:
  client_id=...
  grant_type=authorization_code
  code=AUTH_CODE
  redirect_uri=https://example.com/callback
  client_secret=SECRET  // omit for PKCE
  code_verifier=VERIFIER // required for PKCE

Шаблон поля App Registration (рекомендуемая конфигурация):

Supported account types: Accounts in this organizational directory only (Single tenant) или Multitenant в зависимости от цели.
Redirect URIs: https://yourapp.example.com/auth/callback (точно соответствовать)
API permissions: openid, profile, email, offline_access, Microsoft Graph delegated scopes as needed.

Тестовые случаи (acceptance criteria)

TC1: Пользователь успешно проходит вход и получает id_token
TC2: Access token позволяет вызвать защищённый API и получить 200 OK
TC3: При истечении access_token клиент использует refresh_token и получает новый access_token
TC4: При отзыве согласия администратором приложение теряет доступ к данным

Заключение

OpenID Connect в Azure AD — современный, гибкий и безопасный способ реализовать SSO для веб‑и мобильных приложений. Он хорошо подходит для новых проектов и интеграций с внешними партнёрами. Ключ к надёжной реализации — корректная регистрация приложения, минимизация запрашиваемых разрешений, использование PKCE для публичных клиентов и строгая политика жизни токенов.

Важно: OIDC не решает все задачи безопасности сам по себе — его нужно интегрировать в общий набор мер: Conditional Access, MFA, аудит и мониторинг.

Сводка:

OIDC даёт удобный SSO‑поток с id_token и access_token.
В Azure AD приложение регистрируется через App registrations/Enterprise applications.
Настройка разрешений и согласия (Consent) контролирует, кто и какие данные сможет получить.
Применяйте PKCE, короткие сроки жизни токенов и Conditional Access для усиления безопасности.