Вход по корпоративной учётной записи (OIDC)
Актуально для: SimpleTwo 0.9.x · Проверено: 20.09.2026
Координатор выступает доверяющей стороной OpenID Connect (OIDC Relying Party): человек входит той же учётной записью, что и в остальные корпоративные системы, а SimpleTwo заводит ему аккаунт при первом входе и держит профиль в актуальном состоянии по данным провайдера.
Проверено с Entra ID (Azure AD), ADFS, Keycloak, Okta и Google. Подписи ID-токена проверяются по ключам из JWKS провайдера, алгоритм RS256 — тот, что эти провайдеры используют по умолчанию.
Прямого SAML в координаторе нет. Провайдер, который говорит только на SAML, подключается через ADFS или Entra ID: для SimpleTwo они выглядят обычным OIDC, а SAML остаётся между ними и вашим провайдером. Пункт меню в консоли называется «Single sign-on (OIDC)» именно поэтому.
1. Что нужно завести у провайдера
Одно приложение (app registration) с типом «веб» и адресом возврата:
https://<адрес координатора>/admin/api/sso/callback
Адрес возврата подставляется сам из публичного адреса координатора — менять его в настройке нужно только если перед координатором стоит свой домен или прокси.
Запрашиваемые области по умолчанию — openid email profile groups. Группы нужны для
сопоставления с ролями; если провайдер отдаёт их под другим именем области (частый случай —
Entra ID, где группы приходят без отдельной области), исправьте поле Scopes и имя claim'а.
2. Настройка в консоли
Settings → Single sign-on (OIDC):
| Поле | Что это | По умолчанию |
|---|---|---|
| Issuer | адрес издателя; настройки берутся из <issuer>/.well-known/openid-configuration | — |
| Client ID / Client secret | учётные данные приложения у провайдера | — |
| Redirect URL | адрес возврата | <публичный адрес>/admin/api/sso/callback |
| Scopes | области через пробел | openid email profile groups |
| Email claim | claim с адресом — он же имя учётной записи | email |
| Name claim | claim с отображаемым именем | name |
| Groups claim | claim со списком групп | groups |
| Group → role | сопоставление групп провайдера с ролями SimpleTwo | пусто |
| Default role | роль тем, кто не попал ни в одно правило | пусто |
Человек, чьи группы не совпали ни с одним правилом, не получит доступ: в журнале
появится событие sso.no_role со списком его групп. Это удобный способ настроить
сопоставление — попробуйте войти, посмотрите, какие группы пришли на самом деле, и внесите
их в таблицу. Заполненная «Default role» открывает вход всей организации, поэтому ставьте
её осознанно.
Поток входа — authorization code с state, nonce и PKCE; ID-токен проверяется по
подписи, издателю, аудитории и сроку. Ничего из этого не настраивается — это условия, при
которых токен принимается.
3. Профиль: какие поля приходят из каталога
Кроме почты, имени и групп координатор умеет забирать произвольные атрибуты профиля — должность, подразделение, телефон, город, руководителя. Каждому полю в Groups / roles → profile задаётся источник:
- из claim'а — значение приходит от провайдера и обновляется при каждом входе; человек его не редактирует;
- своё — человек заполняет сам в клиенте.
Поле, чьё имя или claim означает дату рождения, распознаётся автоматически и получает особую обработку: год виден только владельцу, колле гам отдаются день и месяц. Обрезка делается на сервере, а не в интерфейсе, и нечитаемое значение отбрасывается целиком, а не отдаётся как есть.
Руководителя лучше передавать не адресом, а парой user_dn / manager_dn — как это
настроить в ADFS и почему именно так, написано в статье про ADFS.
4. Домены организации
Клиент находит контур по домену рабочей почты: человек вводит ivan@example.com, приложение
само определяет, к какому координатору идти. Домены перечисляются в той же настройке, а
кнопка проверки (POST /admin/api/sso/domains/check) показывает, что видит клиент.
Домен, который обслуживает другая установка, добавлять сюда не нужно: взаимодействие между установками — это федерация, отдельный механизм.
5. Как это выглядит у пользователя
- В браузере (админ-консоль, веб-клиент) — обычный переход к провайдеру и обратно.
- В приложении — человек вводит рабочую почту и пароль в самом клиенте. Координатор проверяет их у провайдера (password grant) и, если провайдер подтвердил, заводит или обновляет учётную запись. Пароль в SimpleTwo не хранится и не сравнивается локально: у учётной записи из каталога здесь просто нет пароля.
SimpleTwo не переписывает введённый адрес. ADFS по умолчанию сверяет его с userPrincipalName,
поэтому сотрудник с UPN ivan@corp.local и почтой ivan@example.com получит «неверные
учётные данные», хотя пароль верный. Лечится на стороне ADFS — Alternate Login ID,
см. статью про ADFS.
6. Если вход не удался
Смотреть — журнал аудита в консоли (/admin/api/audit), события с префиксом sso.:
| Событие | Что означает | Что делать |
|---|---|---|
sso.password_reject | провайдер не принял пару логин/пароль | проверить, что человек вводит тот идентификатор, который провайдер сверяет (UPN или ALI) |
sso.no_role | вход прошёл, но группы не дали ни одной роли; рядом лежит список пришедших групп | внести группу в Group → role или задать Default role |
Две ошибки, которые выглядят как поломка SimpleTwo, но лечатся у провайдера:
- Группы не приходят вовсе. Проверьте, что claim с группами включён в токен: у ADFS claim попадает в OIDC-токен только с зарегистрированным коротким именем, у Entra ID группы нужно явно добавить в конфигурацию токена.
- Другой алгоритм подписи. Принимается RS256. Провайдер, подписывающий ES256, сейчас не п оддерживается — это видно по отказу проверки подписи в журнале.
Дальше
- ADFS: вход по почте и руководитель из каталога
- Гости, подрядчики и члены семьи — доступ тем, кого в каталоге нет
- Федерация между установками