Подключить провайдер 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 сам обнаруживает конечные точки по стандартному документу обнаружения издателя — никакой настройки под отдельного провайдера.
3. У провайдера зарегистрируйте для этого клиента перенаправление https://<your-server>/oidc/callback.
4. Если ваши группы лежат в утверждении, отличном от groups, задайте имя Claim групп; при желании сопоставьте группы с ролями (SSO никогда не может выдать роль владельца).
5. Выберите политику членства (автоматически добавлять во все рабочие пространства или требовать приглашение в каждое рабочее пространство), включите Вход через OpenID Connect и нажмите Сохранить подключение.
6. Нажмите Проверить подключение — сервер загружает документ обнаружения издателя и подтверждает его конечные точки, поэтому зелёное всплывающее уведомление означает, что работает всё, кроме похода в браузер. Чтобы проверить ещё и регистрацию клиента, воспользуйтесь проверкой ниже.
7. Выполните вход: на экране подключения в веб-клиенте показывается Войти через OpenID Connect, или откройте https://<your-server>/oidc/login напрямую.

Утверждения (email, name, groups) читаются вашим сервером с конечной точки токена издателя по 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 работает, пока браузеры пользователей дотягиваются до него (локальная сеть, VPN, Tailscale или туннель). Исключение — провизионинг по SCIM: IdP обращается к вашему серверу напрямую, а для этого нужен туннель или публичный URL — см. настроить пользователей через SCIM.

Проверьте конфигурацию прямо на этой странице

Проверка ниже выполняется в вашем браузере. Она напрямую загружает документ обнаружения вашего издателя, поэтому этот сайт его не видит, и применяет правила сервера: издатель с https, совпадающий с документом, конечные точки на том же origin, что и издатель, 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