Підключити провайдер OpenID Connect

Скористайтеся цим посібником, якщо ваш провайдер ідентичності розмовляє OpenID Connect, а не SAML. Працює будь-який видавець, сертифікований для OIDC, — Pocket ID, Keycloak, Auth0, Zitadel, Google Workspace та інші проходять ті самі кроки; відрізняється лише місце, де ваш провайдер показує ці значення.

Передумови

• провайдер OIDC, у якому ви можете створити клієнт, — занотуйте його ідентифікатор клієнта та URL видавця (базу, під якою розміщено документ .well-known/openid-configuration), а також секрет клієнта, якщо клієнт конфіденційного типу (публічні PKCE-клієнти його не мають),
• сервер Control Center, яким ви адмініструєте (власник сервера).

Кроки

1. Відкрийте Налаштування → Сервер → Єдиний вхід і перемкніться на OpenID Connect.
2. Заповніть URL видавця, Ідентифікатор клієнта і Секрет клієнта (необов’язково), якщо провайдер його видав. Control Center виявляє кінцеві точки зі стандартного discovery-документа видавця — жодного налаштування під конкретного провайдера.
3. У провайдера зареєструйте для цього клієнта редірект https://<your-server>/oidc/callback.
4. Якщо ваші групи містяться в клеймі, відмінному від groups, задайте назву Клейм груп; за бажанням зіставте групи з ролями (SSO ніколи не може надати роль власника).
5. Виберіть політику членства (автоматично додавати до кожного робочого простору або вимагати запрошення для кожного робочого простору), увімкніть Використовувати OpenID Connect для входу і натисніть Зберегти з’єднання.
6. Натисніть Перевірити з’єднання — сервер отримує discovery-документ видавця й підтверджує його кінцеві точки, тож зелене спливаюче сповіщення означає, що працює все, крім обміну через браузер. Щоб перевірити ще й реєстрацію клієнта, скористайтеся інструментом перевірки нижче.
7. Виконайте вхід: екран підключення у вебверсії показує Увійти через OpenID Connect, або відкрийте https://<your-server>/oidc/login напряму.

Твердження (email, ім’я, групи) ваш сервер читає з кінцевої точки токенів видавця через TLS — браузер їх ніколи не надає, тож локальної перевірки підпису JWT не задіяно. Клієнту має бути дозволено запитувати область openid profile email — саме її й просить Control Center.

Оскільки єдине, що автентифікує твердження, — це канал TLS, URL видавця має бути https: видавець у відкритому тексті дав би будь-якому зловмиснику на шляху змогу масово підробляти ідентичності. http приймається лише для видавців на loopback (localhost, 127.0.0.1, ::1) і тільки для локальної розробки.

Публічний клієнт чи конфіденційний клієнт?

Типова — і рекомендована — форма — це публічний клієнт, що використовує потік коду авторизації з PKCE (RFC 7636): одноразовий верифікатор коду, який зберігає сервер, замінює секрет, а обмін токенів прив’язано до запиту авторизації, що його розпочав. Секрету, який міг би витекти, немає, а викрадений код авторизації марний без верифікатора. Деякі провайдери називають цей тип клієнта «SPA» або «native» під час створення.

Якщо ж ваш провайдер видав конфіденційний клієнт, позначте клієнт як публічний у провайдера (PKCE залишається ввімкненим в обох випадках) або вставте секрет клієнта в поле Секрет клієнта (необов’язково) цього з’єднання. Секрет зберігається у файлі секретів сервера з правами 0600 (ніколи в базі даних), надсилається до кінцевої точки токенів як client_secret_post і ніколи не повертається через RPC; якщо залишити поле порожнім під час збереження, збережений секрет залишиться чинним. Коли вхід не вдається на етапі обміну токенів, журнал сервера називає власну помилку провайдера (invalid_client майже завжди означає, що секрет відсутній або хибний).

Досяжність

Сам вхід опосередковує браузер: видавець лише повертає браузер користувача на /oidc/callback, а ваш сервер робить вихідний HTTPS-виклик до кінцевої точки токенів — вхідне з’єднання від видавця не потрібне, тож сервер за NAT працює, доки браузери користувачів можуть до нього дістатися (LAN, VPN, Tailscale або тунель). Виняток — підготовка через SCIM: IdP звертається до вашого сервера напряму, що вимагає тунелю або публічної URL-адреси — див. налаштування користувачів через SCIM.

Перевірте свою конфігурацію на цій сторінці

Інструмент перевірки нижче працює у вашому браузері. Він отримує discovery-документ вашого видавця напряму, тож цей сайт його ніколи не бачить, і застосовує правила сервера: видавець на https, що відповідає документові, кінцеві точки на власному джерелі видавця, PKCE S256 і метод автентифікації токенів, потрібний вашому типу клієнта. Маючи ідентифікатор клієнта й адресу сервера, він може відкрити тестовий вхід, який показує, чи зареєстровано клієнт і його redirect URI. Секрет клієнта він ніколи не запитує.

Runs in your browserYour browser fetches the discovery document straight from your issuer. Add a server address and it also asks that server which sign-in methods it offers. This site never receives what you type.

Issuer URL

Client ID (optional)

Needed for the test sign-in.

Groups claim (optional)

Client type

Public, PKCE only Confidential, has a client secret

Never paste the secret here. The check only needs to know whether one exists.

Server address (optional)

The address your users open. Adds a reachability check and a test sign-in.

Paste the discovery document instead

Discovery document JSON

For providers that block other sites from reading it.

Check issuer