Настройка Azure AD (OIDC)
Пошаговое руководство по настройке единого входа с Microsoft Entra ID (Azure AD) с использованием OpenID Connect.
Предварительные условия
- Тенант Azure AD с admin-доступом
- Учётная запись администратора организации SecureCodingHub
- Домен организации верифицирован в SecureCodingHub
Шаг 1 — Зарегистрируйте приложение в Azure AD
Перейдите в Azure Portal → Microsoft Entra ID → App registrations → New registration
Имя: SecureCodingHub SSO
Supported account types: Accounts in this organizational directory only
Redirect URI: Web → https://api.limeplate.com/api/sch/auth/sso/callback/oidc
Нажмите Register
Шаг 2 — Создайте Client Secret
Перейдите в Certificates & secrets → New client secret
Описание: SecureCodingHub
Срок: Выберите Вашу политику (рекомендуется: 24 месяца)
Скопируйте значение секрета немедленно — оно показывается только один раз
Шаг 3 — Запишите Ваши идентификаторы
Соберите следующие значения из Вашего приложения Azure AD. Они понадобятся Вам на следующем шаге.
| Настройка | Где найти |
|---|---|
| Application (Client) ID | Overview-страница |
| Directory (Tenant) ID | Overview-страница |
| Client Secret | Certificates & secrets |
| Discovery URL | https://login.microsoftonline.com/{tenant-id}/v2.0/.well-known/openid-configuration |
Шаг 4 — Настройте SSO в SecureCodingHub
Войдите как Администратор организации → Настройки SSO
Протокол: OIDC
Entity ID / Client ID: вставьте Ваш Application ID
Discovery / Metadata URL: вставьте Ваш OpenID configuration URL
Client Secret: вставьте секрет
Включите SSO
Нажмите Сохранить
Шаг 5 — Протестируйте
Откройте окно браузера в режиме incognito/private
Перейдите к входу SecureCodingHub
Введите email-адрес с доменом Вашей организации
Вы должны быть перенаправлены к входу Microsoft
После аутентификации Вы должны быть вошедшим в SecureCodingHub
Распространённые ловушки Azure AD SAML
Когда SAML используется с Azure AD вместо OIDC, три режима отказа составляют большинство продакшен-инцидентов. Первый — несоответствие entity ID. Azure AD примет любую строку в поле Identifier раздела SSO, но если она не точно соответствует SP Entity ID, настроенному в SecureCodingHub, SAML-ответ отклоняется с ошибкой audience restriction. Скопируйте идентификатор из страницы настроек SSO SecureCodingHub напрямую, не вводите его. Завершающие слэши и несоответствия протокола (http vs https) — распространённые тихие отказы.
Вторая ловушка — несоответствие claim issuer URI. Azure AD подписывает утверждения URL метаданных федерации, которые он публикует, а SecureCodingHub валидирует, что issuer в SAML-ответе соответствует issuer в метаданных. Если Вы меняете тенанты, регенерируете сертификаты или копируете URL метаданных из другого приложения, issuer разойдётся, и каждый вход будет проваливаться с ошибкой invalid signature. Третья ловушка — размеры group claim. Azure AD усекает group claims, когда утверждение превышает максимальную полезную нагрузку, заменяя группы ссылкой на graph endpoint. Если Вы полагаетесь на group claims для downstream-сопоставления ролей, настройте Azure AD так, чтобы он эмитировал только группы, назначенные приложению, а не все группы, к которым принадлежит пользователь.
Как проверить, что SSO работает от начала до конца
Проверка от начала до конца имеет три этапа. Во-первых, откройте окно incognito и начните вход со страницы входа SecureCodingHub, используя корпоративный email-адрес. Браузер должен перенаправить на login.microsoftonline.com, представить опыт входа Microsoft и затем перенаправить обратно в SecureCodingHub. Если перенаправление обратно не удаётся, захватите адресную строку в момент сбоя. Код ошибки в строке запроса — самый полезный элемент доказательства.
Во-вторых, подтвердите, что пользователь приземляется в правильной организации и панели. Успешный вход с пустой главной страницей или перенаправление на неправильную организацию обычно указывает на отсутствующее сопоставление организация-домен. В-третьих, выйдите, войдите снова и проверьте, что второй вход тихий или почти тихий. Cookie сессии Microsoft должно сделать второй поток почти невидимым. Если оба входа требуют полной повторной аутентификации, Ваше приложение IdP использует политику сессии, не позволяющую переиспользование cookie single sign-on. Для общих шагов устранения неполадок см. Руководство по настройке SAML.