Налаштування SSO
Налаштування SSO
Цей посібник призначений для IT-адміністратора, який підключає корпоративний постачальник посвідчення (IdP) до InterMIND. Після налаштування учасники входять із звичайної сторінки входу: Увійти через SSO → робоча електронна пошта → ваш IdP → повернення в InterMIND. Для нетехнічного огляду перегляньте сторінку функції єдиного входу (Single Sign-On).
Доступно для: планів Business та Enterprise Налаштовує: власник команди або адміністратор Протокол: Тільки OpenID Connect (OIDC). SAML 2.0 не підтримується — Okta, Microsoft Entra ID та Google Workspace підтримують OIDC.
Передумови
- Підтверджений домен — спочатку підтвердіть свій домен електронної пошти через DNS TXT-запис (див. Керування доменами). Вхід через SSO приймає лише облікові записи, домен електронної пошти яких підтверджено вашою командою; це є межею тенанта.
- IdP, який підтримує OIDC з виявленням (discovery) — він має надавати доступ до
/.well-known/openid-configurationза URL-адресою видавця (Issuer URL). Okta, Microsoft Entra ID та Google всі це підтримують.
Що потрібно зареєструвати у вашому IdP
Створіть OIDC Web Application (Веб-додаток OIDC) у вашому IdP з:
| Параметр | Значення |
|---|---|
| URI перенаправлення (callback) | https://intermind.com/api/auth/sso/callback — також відображається в SSO-картці після вибору OIDC |
| Тип авторизації (Grant type) | Authorization Code (PKCE S256 використовується автоматично) |
| Області доступу (Scopes) | openid email profile |
ID-токен, який видає ваш IdP, має містити email користувача, а домен цієї електронної пошти має бути одним із ваших підтверджених доменів — інакше вхід буде відхилено.
Потім заповніть картку SSO на сторінці інтеграцій:
| Поле | Що вставити |
|---|---|
| Display Name | Будь-яка назва, яку впізнають ваші учасники |
| Issuer URL | Видавець вашого IdP — URL, який надає /.well-known/openid-configuration |
| Authorization URL | authorization_endpoint із цього документа виявлення |
| Client ID / Client Secret | Із додатка, який ви зареєстрували |
Секрет клієнта (Client Secret) шифрується під час зберігання та ніколи не повертається до браузера після збереження.
Okta
- Консоль адміністратора → Applications → Create App Integration → метод входу OIDC, тип додатка Web Application
- URI перенаправлення для входу:
https://intermind.com/api/auth/sso/callback - Призначте користувачів або групи, яким слід надати доступ
- Скопіюйте Client ID та Client Secret
- В InterMIND: Issuer URL = URL вашої організації Okta (напр.
https://acme.okta.com, або видавець вашого сервера авторизації, як-отhttps://acme.okta.com/oauth2/default, якщо ви його використовуєте); Authorization URL =authorization_endpointз<issuer>/.well-known/openid-configuration
Microsoft Entra ID (Azure AD)
- Центр адміністрування Entra → App registrations → New registration
- Платформа Web, URI перенаправлення
https://intermind.com/api/auth/sso/callback - Certificates & secrets → New client secret — негайно скопіюйте секретне Value (Значення)
- Client ID = Application (client) ID на сторінці Overview
- Переконайтеся, що ID-токен містить електронну адресу користувача: Token configuration → Add optional claim → ID → email
- В InterMIND: Issuer URL =
https://login.microsoftonline.com/<tenant-id>/v2.0; Authorization URL =https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize
Google Workspace
Реєстрація додатка не потрібна. У SSO-картці виберіть тип постачальника Google Workspace і збережіть — учасники з ваших підтверджених доменів увійдуть за допомогою свого облікового запису Google та автоматично приєднаються до вашої команди. (Google також можна підключити як універсального постачальника OIDC з видавцем https://accounts.google.com, якщо ви віддаєте перевагу явним обліковим даним клієнта.)
Перевірка підключення
- Відкрийте сторінку входу у вікні в режимі інкогніто/приватному вікні
- Натисніть Увійти через SSO і введіть робочу електронну адресу у вашому підтвердженому домені
- Вас буде перенаправлено до вашого IdP; після автентифікації ви повернетесь в InterMIND увійшовши в систему
- Вхід фіксується в журналі аудиту команди (доступному для експорту зі сторінки Користувачі) як
auth.loginз методомsso
Усунення несправностей
| Симптом | Причина |
|---|---|
| "SSO is not configured" після введення електронної адреси | Немає активної конфігурації SSO, яка відповідає цьому домену електронної пошти — перевірте, чи домен підтверджено, а SSO-картка збережена |
SSO login is not available: plan | План команди більше не включає SSO |
SSO login is not available: domain-not-verified | Домен все ще очікує підтвердження DNS |
SSO login is not available: config-incomplete | Відсутній Client ID або Client Secret — збережіть SSO-картку знову |
SSO login is not available: type-unsupported | Збережений тип постачальника не підтримується процесом входу — видаліть конфігурацію SSO і створіть її знову як OIDC або Google Workspace |
SSO IdP discovery failed | Issuer URL неправильний або не надає доступ до /.well-known/openid-configuration |
| "login session expired, start again" | Між початком входу та зворотним викликом IdP минуло понад 5 хвилин |
| Вхід відхилено після перенаправлення від IdP | IdP повернув електронну адресу за межами підтверджених доменів або взагалі без твердження email (Entra: додайте необов'язкове твердження email) |
Властивості безпеки
Для анкет безпеки: потік SSO використовує Authorization Code з PKCE (S256), state та nonce; підпис ID-токена перевіряється за JWKS IdP (разом із видавцем та аудиторією); IdP є авторитетним лише для доменів, підтверджених через DNS — твердження для будь-якої іншої електронної адреси ніколи не створює сеанс; секрет клієнта OIDC зашифрований під час зберігання; кожен вхід через SSO потрапляє до командного журналу аудиту. Перевірки плану, домену та конфігурації виконуються на стороні сервера як на початку входу, так і під час зворотного виклику (callback).