J’ai réussi à connecter GitLab et Microsoft (Azure) avec ce plugin. Au fait : pour le service Azure AD, assurez-vous d’utiliser l’« Application Client ID » comme ID client, et non l’ID secret ou la valeur).\n\nComment est-il possible de connecter Discourse avec deux fournisseurs OIDC, par exemple GitLab et Azure ?\n\nEDIT : J’ai réussi à faire fonctionner la connexion GitLab avec OAuth2, donc ma question est maintenant plus « théorique ».
Je pense que vous devriez forker le plugin et changer son nom pour pouvoir le configurer deux fois. Peut-être le forker et le coder en dur pour l’un de ces services.
Je vois que le fork n’est plus aussi approprié depuis que le plugin OpenID Connect a été intégré au cœur et que son dépôt Git a été archivé.
Cependant, je souhaite enregistrer deux applications (une application par locataire). Puisque l’enregistrement de l’application d’un locataire fonctionne déjà avec le plugin OpenID Connect, puis-je ajouter l’ID de la deuxième application, son secret et l’URL de découverte dans les paramètres ci-dessous ?
Je pense que la solution à ce titre de sujet se trouve dans le message précédent : vous n’avez pas besoin d’utiliser deux OIDC, mais plutôt un OIDC et un Microsoft_auth.
microsoft_auth_email_verified ne ferait pas en sorte que Microsoft Auth se comporte comme le flux OIDC déjà configuré. À ma connaissance, cela permet simplement à Discourse de considérer par défaut les e-mails fournis par Microsoft comme vérifiés/fiables, ce qui peut faciliter la liaison des comptes ou éviter la création de comptes en double si ces e-mails sont réellement vérifiés :
Pour le texte du bouton, OIDC se trouve bien dans l’espace de noms de texte js.login.oidc :
Et Microsoft Auth semble utiliser l’espace de noms de traduction microsoft_office365 plutôt que oidc — par exemple, ce rapport de bug mentionne en.login.microsoft_office365.name :
Je pense donc que l’espace de noms de clés de texte pertinent pour Microsoft Auth est microsoft_office365, et non oidc.