Discourse OpenID Connect (OIDC)

[Discourse]

	Resumen	Discourse OpenID Connect permite utilizar un proveedor OpenID Connect como proveedor de autenticación para Discourse.
	Guía de instalación	Este plugin viene incluido en el núcleo de Discourse. No es necesario instalarlo por separado.

Dado que se trata de un plugin #oficial mantenido por el equipo de Discourse, las solicitudes de Contribute > Bug, Contribute > UX y Contribute > Feature pueden realizarse en las categorías correspondientes aquí en Meta, etiquetadas con la etiqueta del plugin adecuada. El soporte se ofrece en Support > SSO. Haz clic en un enlace a continuación para iniciar uno.

Soporte Error UX Funcionalidad

Funcionalidades

El plugin tiene como objetivo proporcionar una implementación mínima de la especificación. En concreto, admite el “Flujo de código de autorización”. Para empezar, sigue las instrucciones de instalación del plugin o contacta con tu proveedor de alojamiento.

Nuestro plugin oauth2-basic puede utilizarse para conectarse a algunos proveedores openid-connect (OpenID Connect se basa en OAuth2). Sin embargo, este plugin debería requerir mucha menos configuración manual y puede hacer uso del “token de identidad” JWT si no está disponible una API JSON.

La configuración se realiza automáticamente utilizando un documento de descubrimiento OpenID Connect. Según la especificación, este debería estar ubicado en <dominio del emisor>/.well-known/openid-configuration, pero Discourse admite cualquier ruta para permitir implementaciones que no cumplan la norma (por ejemplo, Azure B2C). El documento de descubrimiento se almacena en caché durante 10 minutos para mejorar el rendimiento en sitios con mucho tráfico.

Si el documento de descubrimiento incluye un parámetro userinfo_endpoint, el plugin lo utilizará para recopilar metadatos del usuario. Si no, el plugin extraerá los metadatos del id_token (un JWT) proporcionado por el punto final del token. El plugin NO verifica la autenticidad de la firma JWT, ya que esto aumentaría significativamente la complejidad. Esta decisión está respaldada por la especificación:

Si el token de identidad se recibe mediante comunicación directa entre el cliente y el punto final del token (que es el caso en este flujo), la validación del servidor TLS PUEDE utilizarse para validar el emisor en lugar de verificar la firma del token.

Para los proveedores de identidad que admiten autorización sin secreto utilizando el “Flujo de código de autorización con clave de prueba para el intercambio de código”, PKCE debe estar habilitado y la configuración client_secret puede omitirse.

Configuración

Opciones de configuración básica

• openid_connect_enabled: Habilitar la autenticación OpenID Connect

• openid_connect_discovery_document: URL del documento de descubrimiento OpenID Connect. Normalmente ubicado en https://tu.dominio/.well-known/openid-configuration

• openid_connect_client_id: ID de cliente OpenID Connect

• openid_connect_client_secret: Secreto de cliente OpenID Connect

• openid connect rp initiated logout: Redirigir al usuario al end_session_endpoint después del cierre de sesión. Debe ser admitido por tu proveedor de identidad e incluido en el documento de descubrimiento.

• openid connect rp initiated logout redirect: (opcional) El post_logout_redirect_uri que se pasará al punto final de cierre de sesión. Si se proporciona, debe estar registrado con el proveedor de identidad.

• openid_connect_authorize_scope: Los ámbitos enviados al punto final de autorización. Esto debe incluir ‘openid’

• openid_connect_use_pkce: Habilitar la clave de prueba para el intercambio de código (PKCE) para la autenticación OpenID Connect.

• openid_connect_verbose_logging: Registrar información detallada de autenticación openid-connect en /logs. Mantén esto deshabilitado durante el uso normal.

Opciones de configuración avanzada

• openid_connect_token_scope: Los ámbitos enviados al solicitar el punto final del token. La especificación oficial no lo requiere.

• openid_connect_error_redirects: Si la error_reason de la devolución de llamada contiene el primer parámetro, el usuario será redirigido a la URL en el segundo parámetro. Se utiliza para implementaciones inusuales que envían errores en respuesta a la entrada del usuario (por ejemplo, Azure B2C)

• openid_connect_allow_association_change: Permitir que los usuarios desconecten y reconecten sus cuentas de Discourse del proveedor OpenID Connect

• openid_connect_groups_claim: El nombre de la reclamación en la respuesta OIDC^[1] que contiene los grupos del usuario como una matriz de cadenas. Déjalo en blanco para deshabilitar la sincronización de grupos. Consulta Sincronización de grupos a continuación.

• openid_connect_user_field_mappings: Mapeos de reclamaciones OIDC^[2] que se almacenarán en los campos de usuario de Discourse. Los campos de usuario se identifican por su ID numérico, que se puede encontrar en la URL al editarlos a través del panel de administración.

Sincronización de grupos

El plugin puede sincronizar automáticamente las membresías de grupos desde tu proveedor OpenID Connect con los grupos de Discourse. En cada inicio de sesión, el plugin leerá la reclamación configurada del token OIDC y actualizará las membresías de grupos del usuario en consecuencia. Para habilitar la sincronización de grupos:

1. Configura tu proveedor de identidad para que devuelva una matriz de grupos en una de las reclamaciones. Debe ser una matriz de cadenas.

2. Establece openid_connect_groups_claim en el nombre de la reclamación en el token OIDC que contiene los grupos del usuario (por ejemplo, cognito:groups). Una vez establecido, comenzará a sincronizar la información con el sistema de “Grupos asociados” de Discourse.

3. Encuentra el grupo de Discourse que deseas vincular. Ve a “Configuración” → “Membresía” → “Automático” y luego elige los Grupos asociados para vincular. Esta lista desplegable se completa con información del proveedor de identidad, por lo que al menos un miembro del grupo debe haber iniciado sesión para que aparezca una opción.

Configuración de ejemplo

Aquí configuraremos el plugin openid-connect para conectarse al proveedor OpenID Connect de Google. Esto replica una funcionalidad que ya existe en el núcleo de Discourse, pero sirve como un ejemplo accesible.

1. Ve a OpenID Connect  |  Sign in with Google  |  Google for Developers y sigue las instrucciones para obtener las credenciales de OAuth.

2. En la misma página, sigue las instrucciones para agregar una URI de redirección. Debería ser https://<tu_foro>/auth/oidc/callback (sin una barra al final)

3. Ve a la configuración de tu sitio de Discourse y busca “openid_connect”

   • openid connect enabled: [x]

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

   • openid connect client id: <id-de-cliente>

   • openid connect client secret: <secreto-de-cliente>

   • openid connect authorize scope: openid email (con un espacio en medio)

4. ¡Listo! El botón “Iniciar sesión con OpenID Connect” ahora iniciará sesión usando Google . Estos mismos pasos se pueden aplicar a otros proveedores con cambios muy mínimos.

Depuración

Además de la configuración verbose_logging descrita anteriormente, puedes acceder a datos sobre las asociaciones OIDC utilizando el plugin data-explorer:

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

O en la consola de rails:

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

Notas específicas del proveedor

Siéntete libre de actualizar esto si encuentras cualquier peculiaridad específica del proveedor relacionada con esta integración:

Entra ID (anteriormente Azure AD)

Agrega el ámbito email y asegúrate de estar utilizando el documento de configuración del punto final de versión 2. Por ejemplo

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

@andy.czerwonka

• Asegúrate de usar la versión 2.0 del punto final de configuración según las notas anteriores. El punto final v1.0 predeterminado no admite los ámbitos email o profile.
• Si hay problemas con el secreto del cliente, intenta generar uno nuevo. Tuvimos algunos problemas, pero después de generar un par, parecía estar bien.
• Asegúrate de activar “Iniciar sesión y leer el perfil del usuario” como un “Permiso delegado” en Azure AD al crear la entrada para tu sitio.
• Asegúrate de agregar la devolución de llamada correcta, que es ‘https://tu-sitio/auth/oidc/callback’

Azure B2C

Los detalles de la URL del documento de descubrimiento se pueden encontrar aquí: Web sign in with OpenID Connect - Azure AD B2C | Microsoft Learn

Por ejemplo, el documento de metadatos para el flujo de usuario b2c_1_sign_in en fabrikamb2c.onmicrosoft.com se encuentra en:

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

Para que funcionen los correos electrónicos:

@Umer_Nawab

Para obtener el correo electrónico en las reclamaciones, tendrás que usar políticas personalizadas. Para lograrlo, utilicé el paquete de inicio de políticas mencionado aquí:

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

Después de implementar los pasos mencionados en el artículo anterior, la reclamación de correo electrónico comenzó a aparecer cuando el usuario se registró, pero cuando un usuario existente inició sesión, la reclamación de correo electrónico faltaba en el token. Luego tuve que hacer algunos cambios en el archivo XML de la política personalizada siguiendo los pasos mencionados en esta publicación:

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

Después de estos cambios, la reclamación de correo electrónico ahora aparece cuando el usuario se registra y también cuando el usuario inicia sesión.

Yahoo

1. Ve a https://developer.yahoo.com/apps y crea una nueva aplicación

2. Ingresa el nombre de la aplicación y establece el dominio de devolución de llamada en el dominio de tu foro (por ejemplo, meta.discourse.org)

3. En Permisos de API, elige Perfiles: Lectura/escritura pública y privada. Esta es la única forma que conozco para obtener la dirección de correo electrónico del usuario

4. Guarda la aplicación

5. En la configuración de OIDC de Discourse, establece el documento de descubrimiento en

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

6. Ingresa el ID de cliente y el secreto de Yahoo

7. Habilita el plugin OIDC

AWS Cognito

1. Ve a Cognito y selecciona o crea un nuevo grupo de usuarios.
2. Define una aplicación en Clientes de aplicaciones.
3. Deja todo por defecto, pero cambia la configuración de flujos de autenticación para seleccionar solo ALLOW_REFRESH_TOKEN_AUTH.
4. Ve a la configuración del cliente de la aplicación y selecciona la nueva aplicación.
5. Cambia la URL de devolución de llamada a https://tusitio.ejemplo.com/auth/oidc/callback.
6. Marca solo el flujo de concesión de código de autorización entre “Flujos OAuth permitidos”.
7. Marca todos los ámbitos necesarios (yo tengo todos marcados).

Okta

1. Configura Discourse con el ID de cliente y el secreto de tu aplicación Okta

2. Establece la URL del documento de descubrimiento en

   https://{tu-app}.okta.com/.well-known/openid-configuration
   

3. En Discourse, establece openid connect authorize scope en openid email

¿Alojado por nosotros? Este plugin está disponible en nuestros planes Business y Enterprise. OAuth 2.0 & OpenID Connect Support | Discourse - Civilized Discussion

¿Necesitas automatizar el registro de usuarios? Consulta Auto-provisioning user accounts when SSO is enabled

---

1. token o payload de userinfo ↩︎

2. desde el token o el payload de userinfo ↩︎