Logré conectar GitLab y Microsoft (Azure) con este plugin. Por cierto: para el servicio de Azure AD, asegúrate de usar el “Application Client ID” como ID de cliente, no el ID secreto ni el valor).
¿Cómo es posible conectar Discourse con dos proveedores OIDC, por ejemplo, GitLab y Azure?
EDITAR: Logré que el inicio de sesión de GitLab funcione con OAuth2, por lo que mi pregunta es ahora más “teórica”.
Creo que necesitarías bifurcar el plugin y cambiar su nombre para poder configurarlo dos veces. Quizás lo bifurcarías y lo codificarías para uno de esos servicios.
Veo que ya no es tan apropiado hacer un fork desde que el plugin Open ID Connect se integró en el núcleo y su repositorio de Git fue archivado.
Sin embargo, me gustaría registrar dos aplicaciones (una aplicación por inquilino). Como ya tengo el registro de la aplicación de un inquilino funcionando con el plugin Open ID Connect, ¿podría colocar el ID de la segunda aplicación, el secreto y la URL de descubrimiento en la configuración de abajo?
Creo que la solución para este título del tema está en el post anterior: no necesitas usar dos OIDC, sino un OIDC y uno Microsoft_auth.
microsoft_auth_email_verified no haría que la autenticación de Microsoft se comportara como el flujo OIDC ya configurado. Mi entendimiento es que solo hace que Discourse trate los correos electrónicos proporcionados por Microsoft como verificados/de confianza por defecto, lo cual puede ayudar con la vinculación de cuentas / evitar cuentas duplicadas si esos correos electrónicos están genuinamente verificados:
Para el texto del botón, OIDC definitivamente está bajo el espacio de nombres de texto js.login.oidc:
Y la autenticación de Microsoft parece usar el espacio de nombres de traducción microsoft_office365 en lugar de oidc; por ejemplo, este informe de error menciona en.login.microsoft_office365.name:
Por lo tanto, creo que el espacio de nombres de clave de texto relevante para la autenticación de Microsoft es microsoft_office365, no oidc.
