Дайте команді входити з тим обліковим записом, який у неї вже є у вашого провайдера ідентифікації — Okta, Entra ID, Google Workspace або будь-якого іншого з підтримкою OpenID Connect. Налаштовують адміністратори компанії самі, у розділі Профіль → Єдиний вхід.
Налаштування складається з трьох кроків, і порядок тут важливий: кожен наступний заблоковано, доки не зроблено попередній.
Додайте домен, на якому працює пошта команди (те, що стоїть після @), опублікуйте TXT-запис із
картки й натисніть Перевірити DNS.
Саме підтверджений домен дає вашому провайдеру право говорити від імені цих адрес. Без нього вхід через провайдера доводить лише те, звідки прийшло твердження, але не те, за кого він має право ручатися, — тому всі такі входи відхиляються.
Два моменти, які варто знати:
gmail.com, outlook.com і подібні відхиляються одразу:
їхній DNS не належить жодному клієнту, а отже підтвердити їх неможливо.Цей крок за своєю природою замкнений у коло, тому почніть із redirect URI: зареєструвати Oiva у провайдера не можна, не знаючи, куди він повертає користувача, а отримати client ID і секрет не можна, не зареєструвавши застосунок.
https://acme-analytics.okta.com.Зберігається лише issuer. Адреси authorize і token, а також ключі підпису щоразу читаються з його discovery-документа, тож ротація ключів на вашому боці тут нічого не потребуватиме.
Під час збереження ми один раз звертаємося до провайдера, щоб переконатися, що issuer існує, — інакше помилка в написанні спливла б лише під час першого входу співробітника. Якщо прочитати конфігурацію не вдалося, у помилці буде названо issuer, до якого ми зверталися.
Останній крок навмисно відокремлено від попереднього, і проміжок між ними — саме те місце, де ви переконуєтеся, що вхід справді працює для ваших людей. Спершу нехай хтось увійде через провайдера.
Після ввімкнення пароль перестає пускати до цієї компанії. Членство в будь-яких інших компаніях не зачіпається: вимога належить членству, а не людині.
Вимкнення назад ніколи не запитує підтвердження. Це напрямок, який повертає доступ, тож він завжди в один клік.
Людина, яка приходить через вашого провайдера вперше, отримує обліковий запис автоматично, з роллю за замовчуванням із кроку 2.
Запрошення це змінює. Запросіть співробітника на адресу всередині підтвердженого домену — і запрошення стає бронюванням ролі: перший вхід через провайдера витратить його, і людина потрапить із обраною вами роллю, а не з роллю за замовчуванням. Так адміністратора можна завести заздалегідь, ще до його першого входу.
Підряднику на особистій адресі, як і раніше, надходить звичайне запрошення з паролем — ваш провайдер не може ручатися за адресу, яка йому не належить.
Єдиний вхід вмикає вже наявний адміністратор, тому хтось завжди реєструється звичайним способом першим. Якщо ця людина використала корпоративну адресу, робити нічого не треба: її перший вхід через провайдера прив'яжеться до вже наявного облікового запису, і вона збереже компанію, роль і все, що їй належить.
Якщо адреса була особиста, ці двоє ніколи не зустрінуться — gmail.com підтвердити не можна, — і
людина щоразу потраплятиме на форму з паролем. Щоб перейти: