Discourse OpenID Connect (OIDC)

[Discourse]

	Краткое содержание	Discourse OpenID Connect позволяет использовать провайдера OpenID Connect в качестве провайдера аутентификации для Discourse.
	Руководство по установке	Этот плагин включен в ядро Discourse. Отдельная установка плагина не требуется.

Поскольку это #официальный плагин, поддерживаемый командой Discourse, запросы на Contribute > Bug, Contribute > UX и Contribute > Feature можно направлять в соответствующие категории здесь, на Meta, с использованием соответствующего тега плагина. Поддержка предоставляется в категории Support > SSO. Нажмите на ссылку ниже, чтобы начать.

Поддержка Ошибка UX Функция

Возможности

Плагин стремится обеспечить минимальную реализацию спецификации. В частности, он поддерживает «поток авторизационного кода» (Authorization Code Flow). Для начала работы следуйте инструкциям по установке плагина или обратитесь к вашему хостинг-провайдеру.

Наш плагин oauth2-basic можно использовать для подключения к некоторым провайдерам OpenID Connect (OpenID Connect основан на OAuth2). Однако этот плагин требует значительно меньше ручной настройки и может использовать JWT «ID Token», если JSON API недоступен.

Настройка автоматически выполняется с использованием документа обнаружения OpenID Connect. Согласно спецификации, он должен находиться по адресу <domain_издателя>/.well-known/openid-configuration, но Discourse поддерживает любой путь для совместимости с не соответствующими спецификации реализациями (например, Azure B2C). Документ обнаружения кэшируется на 10 минут для повышения производительности на сайтах с высоким трафиком.

Если документ обнаружения включает параметр userinfo_endpoint, плагин использует его для сбора метаданных пользователя. В противном случае плагин извлекает метаданные из id_token (JWT), предоставленного конечной точкой токена. Плагин НЕ проверяет подлинность подписи JWT, так как это значительно усложнило бы систему. Это решение поддерживается спецификацией:

Если ID Token получен через прямую коммуникацию между клиентом и конечной точкой токена (что имеет место в данном потоке), для проверки издателя может использоваться валидация TLS-сервера вместо проверки подписи токена.

Для провайдеров идентификации, поддерживающих авторизацию без секрета с использованием «Потока авторизационного кода с доказательством ключа для обмена кодом» (PKCE), следует включить PKCE, а параметр конфигурации client_secret можно опустить.

Конфигурация

Базовые параметры конфигурации

• openid_connect_enabled: Включить аутентификацию OpenID Connect

• openid_connect_discovery_document: URL документа обнаружения OpenID Connect. Обычно находится по адресу https://your.domain/.well-known/openid-configuration

• openid_connect_client_id: ID клиента OpenID Connect

• openid_connect_client_secret: Секрет клиента OpenID Connect

• openid connect rp initiated logout: Перенаправлять пользователя на end_session_endpoint после выхода. Должно поддерживаться вашим провайдером идентификации и быть указано в документе обнаружения.

• openid connect rp initiated logout redirect: (опционально) post_logout_redirect_uri, который будет передан конечной точке выхода. Если указан, он должен быть зарегистрирован у провайдера идентификации.

• openid_connect_authorize_scope: Сферы доступа (scopes), отправляемые на конечную точку авторизации. Должна включать ‘openid’

• openid_connect_use_pkce: Включить Proof Key for Code Exchange (PKCE) для аутентификации OpenID Connect.

• openid_connect_verbose_logging: Вести подробное логирование информации об аутентификации openid-connect в /logs. Оставьте это отключенным при обычном использовании.

Расширенные параметры конфигурации

• openid_connect_token_scope: Сферы доступа (scopes), отправляемые при запросе к конечной точке токена. Официальная спецификация не требует этого.

• openid_connect_error_redirects: Если error_reason обратного вызова содержит первый параметр, пользователь будет перенаправлен на URL во втором параметре. Используется для необычных реализаций, отправляющих ошибки в ответ на действия пользователя (например, Azure B2C).

• openid_connect_allow_association_change: Разрешить пользователям отключать и повторно подключать свои учетные записи Discourse от провайдера OpenID Connect.

• openid_connect_groups_claim: Имя утверждения (claim) в ответе OIDC^[1], содержащего группы пользователя в виде массива строк. Оставьте пустым, чтобы отключить синхронизацию групп. См. раздел Синхронизация групп ниже.

• openid_connect_user_field_mappings: Отображение утверждений OIDC^[2], которые будут сохранены в пользовательских полях Discourse. Пользовательские поля идентифицируются их числовым ID, который можно найти в URL при их редактировании через панель администратора.

Синхронизация групп

Плагин может автоматически синхронизировать членство в группах от вашего провайдера OpenID Connect с группами Discourse. При каждом входе плагин считывает настроенное утверждение из токена OIDC и обновляет членство пользователя в группах соответствующим образом. Чтобы включить синхронизацию групп:

1. Настройте вашего провайдера идентификации на возвращение массива групп в одном из утверждений. Это должен быть массив строк.

2. Установите openid_connect_groups_claim в имя утверждения в токене OIDC, содержащего группы пользователя (например, cognito:groups). После установки информация начнет синхронизироваться с системой «Связанные группы» (Associated Groups) в Discourse.

3. Найдите группу Discourse, которую хотите связать. Перейдите в «Настройки» → «Членство» → «Автоматически», а затем выберите «Связанные группы» для связи. Этот выпадающий список заполняется информацией от провайдера идентификации, поэтому для появления опции хотя бы один член группы должен войти в систему.

Пример настройки

Здесь мы настроим плагин openid-connect для подключения к провайдеру OpenID Connect Google. Это повторяет функциональность, уже существующую в ядре Discourse, но служит доступным примером.

1. Перейдите на OpenID Connect  |  Sign in with Google  |  Google for Developers и следуйте инструкциям для получения учетных данных OAuth.

2. На той же странице следуйте инструкциям для добавления URI перенаправления. Он должен быть https://<ваш_форум>/auth/oidc/callback (без завершающего слеша).

3. Перейдите в настройки вашего сайта Discourse и найдите «openid_connect»

   • openid connect enabled: [x]

   • openid connect discovery document: https://accounts.google.com/.well-known/openid-configuration

   • openid connect client id: <id_клиента>

   • openid connect client secret: <секрет_клиента>

   • openid connect authorize scope: openid email (с пробелом между ними)

4. Готово. Кнопка «Войти с помощью OpenID Connect» теперь будет входить через Google . Эти же шаги можно применить к другим провайдерам с минимальными изменениями.

Отладка

В дополнение к параметру verbose_logging, описанному выше, вы можете получить данные о связях OIDC с помощью плагина data-explorer:

SELECT user_id, provider_name, provider_uid
FROM user_associated_accounts
WHERE provider_name = 'oidc'

Или в консоли Rails:

User.find_by_username("david").user_associated_accounts.where(provider_name: 'oidc')

Примечания для конкретных провайдеров

Пожалуйста, не стесняйтесь обновлять этот раздел, если вы обнаружите какие-либо особенности, специфичные для провайдера, связанные с этой интеграцией:

Entra ID (ранее Azure AD)

Добавьте область email и убедитесь, что вы используете документ конфигурации конечной точки версии 2. Например:

https://login.microsoftonline.com/{tenant}/v2.0/.well-known/openid-configuration

@andy.czerwonka

• Убедитесь, что вы используете версию 2.0 конечной точки конфигурации, как указано выше. Конечная точка по умолчанию версии 1.0 не поддерживает области email или profile.
• Если возникнут проблемы с секретом клиента, попробуйте сгенерировать новый. У нас были некоторые проблемы, но после генерации нескольких всё заработало нормально.
• Убедитесь, что вы включили «Вход и чтение профиля пользователя» как «Делегированное разрешение» в Azure AD при создании записи для вашего сайта.
• Убедитесь, что вы добавили правильный обратный вызов, который равен ‘https://your-site/auth/oidc/callback’.

Azure B2C

Подробности URL документа обнаружения можно найти здесь: Web sign in with OpenID Connect - Azure AD B2C | Microsoft Learn

Например, документ метаданных для потока пользователей b2c_1_sign_in в fabrikamb2c.onmicrosoft.com находится по адресу:

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/v2.0/.well-known/openid-configuration?p=b2c_1_sign_in

Чтобы заработала отправка писем:

@Umer_Nawab

Чтобы получить email в утверждениях, вам придется использовать пользовательские политики. Для этого я использовал стартовый набор политик, упомянутый здесь:

Tutorial - Create user flows and custom policies - Azure Active Directory B2C | Microsoft Learn

После выполнения шагов, описанных в статье выше, утверждение email начало появляться при регистрации пользователя, но при входе существующего пользователя утверждение email отсутствовало в токене. Затем мне пришлось внести некоторые изменения в XML-файл пользовательской политики, следуя шагам, описанным в этом посте:

https://stackoverflow.com/questions/59669666/email-claims-not-populated-with-custom-policies-in-azure-b2c

После этих изменений утверждение email теперь появляется как при регистрации пользователя, так и при его входе.

Yahoo

1. Перейдите на https://developer.yahoo.com/apps и создайте новое приложение.

2. Введите имя приложения и установите домен обратного вызова в домен вашего форума (например, meta.discourse.org).

3. В разделе «Разрешения API» выберите Profiles: Read/Write Public and Private. Это единственный известный мне способ получения адреса электронной почты пользователя.

4. Сохраните приложение.

5. В настройках OIDC Discourse установите документ обнаружения в:

   https://login.yahoo.com/.well-known/openid-configuration
   

6. Введите ID клиента и секрет от Yahoo.

7. Включите плагин OIDC.

AWS Cognito

1. Перейдите в Cognito и выберите или создайте новый пул пользователей.
2. Определите приложение в разделе «Клиенты приложений».
3. Оставьте всё по умолчанию, но измените конфигурацию потоков аутентификации, выбрав только ALLOW_REFRESH_TOKEN_AUTH.
4. Перейдите в настройки клиента приложения и выберите новое приложение.
5. Измените URL обратного вызова на https://yoursite.example.com/auth/oidc/callback.
6. Отметьте только поток предоставления авторизационного кода среди «Разрешенных потоков OAuth».
7. Отметьте все необходимые области (я отметил все).

Okta

1. Настройте Discourse с ID клиента и секретом вашего приложения Okta.

2. Установите URL документа обнаружения в:

   https://{ваше_приложение}.okta.com/.well-known/openid-configuration
   

3. В Discourse установите openid connect authorize scope в openid email.

Размещено нами? Этот плагин доступен в наших тарифных планах Business и Enterprise. OAuth 2.0 & OpenID Connect Support | Discourse - Civilized Discussion

Нужно автоматизировать регистрацию пользователей? См. Auto-provisioning user accounts when SSO is enabled

---

1. токен или полезная нагрузка userinfo ↩︎

2. из токена или полезной нагрузки userinfo ↩︎