OpenID Connect (OIDC) pour Discourse

[Discourse]

	Résumé	Discourse OpenID Connect permet d’utiliser un fournisseur OpenID Connect comme fournisseur d’authentification pour Discourse.
	Guide d’installation	Ce plugin est inclus dans le noyau de Discourse. Aucune installation séparée n’est nécessaire.

Comme il s’agit d’un plugin #officiel maintenu par l’équipe Discourse, les demandes de bug, d’améliorations de l’expérience utilisateur (ux) et de nouvelles fonctionnalités (#feature) peuvent être soumises dans les catégories respectives sur Meta, en utilisant le tag approprié du plugin. Le support est disponible dans sso. Cliquez sur un lien ci-dessous pour en créer un.

Support Bug UX Fonctionnalité

Fonctionnalités

Le plugin vise à fournir une implémentation minimale de la spécification. Plus précisément, il prend en charge le « flux de code d’autorisation ». Pour commencer, suivez les instructions d’installation du plugin, ou contactez votre hébergeur.

Notre plugin oauth2-basic peut être utilisé pour se connecter à certains fournisseurs OpenID Connect (OpenID Connect est basé sur OAuth2). Cependant, ce plugin nécessite beaucoup moins de configuration manuelle et peut utiliser le « ID Token » JWT si une API JSON n’est pas disponible.

La configuration est effectuée automatiquement à l’aide d’un document de découverte OpenID Connect. Selon la spécification, celui-ci devrait se trouver à <domaine_d'émetteur>/.well-known/openid-configuration, mais Discourse prend en charge n’importe quel chemin pour permettre des implémentations non conformes (par exemple Azure B2C). Le document de découverte est mis en cache pendant 10 minutes pour améliorer les performances sur les sites à fort trafic.

Si le document de découverte inclut un paramètre userinfo_endpoint, le plugin l’utilisera pour collecter les métadonnées de l’utilisateur. Sinon, le plugin extraira les métadonnées du id_token (un JWT) fourni par le point de terminaison du jeton. Le plugin NE vérifie PAS l’authenticité de la signature JWT, car cela augmenterait considérablement la complexité. Cette décision est soutenue par la spécification :

Si le ID Token est reçu via une communication directe entre le client et le point de terminaison du jeton (ce qui est le cas dans ce flux), la validation du serveur TLS PEUT être utilisée pour valider l’émetteur au lieu de vérifier la signature du jeton.

Pour les fournisseurs d’identité qui prennent en charge l’autorisation sans secret en utilisant le « flux de code d’autorisation avec clé de preuve pour l’échange de code », PKCE doit être activé et la configuration client_secret peut être omise.

Configuration

Options de configuration de base

• openid_connect_enabled: Activer l’authentification OpenID Connect

• openid_connect_discovery_document : URL du document de découverte OpenID Connect. Normalement situé à https://votre.domaine/.well-known/openid-configuration

• openid_connect_client_id : ID du client OpenID Connect

• openid_connect_client_secret : Secret du client OpenID Connect

• openid connect rp initiated logout : Rediriger l’utilisateur vers end_session_endpoint après la déconnexion. Doit être pris en charge par votre fournisseur d’identité et inclus dans le document de découverte.

• openid connect rp initiated logout redirect : (facultatif) Le post_logout_redirect_uri qui sera transmis au point de terminaison de déconnexion. Si fourni, il doit être enregistré auprès du fournisseur d’identité.

• openid_connect_authorize_scope : Les portées envoyées au point de terminaison d’autorisation. Cela doit inclure ‘openid’

• openid_connect_use_pkce : Activer la clé de preuve pour l’échange de code (PKCE) pour l’authentification OpenID Connect.

• openid_connect_verbose_logging : Journaliser les informations détaillées d’authentification openid-connect dans /logs. Gardez ceci désactivé lors de l’utilisation normale.

Options de configuration avancées

• openid_connect_token_scope : Les portées envoyées lors de la demande au point de terminaison du jeton. La spécification officielle ne l’exige pas.

• openid_connect_error_redirects : Si la raison de l’erreur de rappel contient le premier paramètre, l’utilisateur sera redirigé vers l’URL du second paramètre. Utilisé pour des implémentations inhabituelles qui envoient des erreurs en réponse à une saisie utilisateur (par exemple Azure B2C)

• openid_connect_allow_association_change : Permettre aux utilisateurs de déconnecter et reconnecter leurs comptes Discourse du fournisseur OpenID Connect

• openid_connect_groups_claim : Le nom de la revendication dans la réponse OIDC^[1] qui contient les groupes de l’utilisateur sous forme de tableau de chaînes. Laissez vide pour désactiver la synchronisation des groupes. Voir Synchronisation des groupes ci-dessous.

• openid_connect_user_field_mappings : Mappages des revendications OIDC^[2] qui seront stockées dans les champs utilisateur de Discourse. Les champs utilisateur sont identifiés par leur ID numérique, que vous pouvez trouver dans l’URL lors de leur édition via le panneau d’administration.

Synchronisation des groupes

Le plugin peut automatiquement synchroniser les adhésions aux groupes de votre fournisseur OpenID Connect avec les groupes Discourse. À chaque connexion, le plugin lira la revendication configurée depuis le jeton OIDC et mettra à jour les adhésions aux groupes de l’utilisateur en conséquence. Pour activer la synchronisation des groupes :

1. Configurez votre fournisseur d’identité pour retourner un tableau de groupes dans l’une des revendications. Cela doit être un tableau de chaînes.

2. Définissez openid_connect_groups_claim sur le nom de la revendication dans le jeton OIDC qui contient les groupes de l’utilisateur (par exemple cognito:groups). Une fois défini, cela commencera à synchroniser les informations vers le système « Groupes associés » de Discourse.

3. Trouvez le groupe Discourse que vous souhaitez lier. Allez dans « Paramètres » > « Adhésion » > « Automatique », puis choisissez les groupes associés à lier. Cette liste déroulante est remplie par les informations du fournisseur d’identité, donc au moins un membre du groupe doit s’être connecté pour qu’une option apparaisse.

Exemple de configuration

Ici, nous allons configurer le plugin openid-connect pour se connecter au fournisseur OpenID Connect de Google. Cela reproduit une fonctionnalité déjà présente dans le noyau de Discourse, mais cela sert d’exemple accessible.

1. Rendez-vous sur OpenID Connect  |  Sign in with Google  |  Google for Developers et suivez les instructions pour obtenir les identifiants OAuth.

2. Sur la même page, suivez les instructions pour ajouter une URI de redirection. Celle-ci doit être https://<votre_forum>/auth/oidc/callback (sans barre oblique finale)

3. Accédez aux paramètres de votre site Discourse et recherchez « openid_connect »

   • openid connect enabled : [x]

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

   • openid connect client id : <client-id>

   • openid connect client secret : <client-secret>

   • openid connect authorize scope : openid email (avec un espace entre les deux)

4. C’est tout. Le bouton « Se connecter avec OpenID Connect » vous connectera désormais via Google . Ces mêmes étapes peuvent être appliquées à d’autres fournisseurs avec des modifications très minimes.

Débogage

En plus du paramètre verbose_logging décrit ci-dessus, vous pouvez accéder aux données sur les associations OIDC en utilisant le plugin data-explorer :

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

Ou dans la console Rails :

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

Notes spécifiques aux fournisseurs

N’hésitez pas à mettre à jour cette section si vous trouvez des particularités spécifiques à un fournisseur liées à cette intégration :

Entra ID (anciennement Azure AD)

Ajoutez la portée email et assurez-vous d’utiliser le document de configuration du point de terminaison version 2. Par exemple

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

@andy.czerwonka

• Assurez-vous d’utiliser la version 2.0 du point de terminaison de configuration comme indiqué dans les notes ci-dessus. Le point de terminaison v1.0 par défaut ne prend pas en charge les portées email ou profile.
• Si vous rencontrez des problèmes avec le secret du client, essayez d’en générer un nouveau. Nous avons eu quelques problèmes, mais après en avoir généré plusieurs, tout semblait fonctionner correctement.
• Assurez-vous d’activer « Se connecter et lire le profil utilisateur » en tant que « Autorisation déléguée » dans Azure AD lors de la création de l’entrée pour votre site.
• Assurez-vous d’ajouter le bon rappel, qui est ‘https://votre-site/auth/oidc/callback’

Azure B2C

Les détails de l’URL du document de découverte se trouvent ici : Web sign in with OpenID Connect - Azure AD B2C | Microsoft Learn

Par exemple, le document de métadonnées pour le flux utilisateur b2c_1_sign_in dans fabrikamb2c.onmicrosoft.com est situé à :

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

Pour que les e-mails fonctionnent :

@Umer_Nawab

Pour obtenir l’e-mail dans les revendications, vous devrez utiliser des politiques personnalisées. Pour y parvenir, j’ai utilisé le pack de démarrage des politiques mentionné ici :

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

Après avoir mis en œuvre les étapes mentionnées dans l’article ci-dessus, la revendication e-mail a commencé à apparaître lorsque l’utilisateur s’inscrivait, mais lorsqu’un utilisateur existant se connectait, la revendication e-mail manquait du jeton. J’ai dû apporter quelques modifications au fichier XML de la politique personnalisée en suivant les étapes mentionnées dans ce post :

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

Après ces modifications, la revendication e-mail apparaît maintenant lorsque l’utilisateur s’inscrit et également lorsqu’il se connecte.

Yahoo

1. Rendez-vous sur https://developer.yahoo.com/apps et créez une nouvelle application

2. Entrez le nom de l’application et définissez le domaine de rappel sur le domaine de votre forum (par exemple meta.discourse.org)

3. Sous Autorisations API, choisissez Profils : Lecture/écriture publique et privée. C’est la seule méthode que je connais pour obtenir l’adresse e-mail de l’utilisateur

4. Enregistrez l’application

5. Dans les paramètres OIDC de Discourse, définissez le document de découverte sur

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

6. Entrez l’ID client et le secret de Yahoo

7. Activez le plugin OIDC

AWS Cognito

1. Accédez à Cognito et sélectionnez ou créez un nouveau pool d’utilisateurs.
2. Définissez une application dans les clients d’application.
3. Laissez tout par défaut, mais modifiez la configuration des flux d’authentification pour sélectionner uniquement ALLOW_REFRESH_TOKEN_AUTH.
4. Accédez aux paramètres du client d’application et sélectionnez la nouvelle application.
5. Modifiez l’URL de rappel en https://votresite.example.com/auth/oidc/callback.
6. Cochez uniquement le flux de délégation de code d’autorisation parmi les « Flux OAuth autorisés ».
7. Cochez toutes les portées nécessaires (j’ai tout coché).

Okta

1. Configurez Discourse avec l’ID client et le secret de votre application Okta

2. Définissez l’URL du document de découverte sur

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

3. Dans Discourse, définissez openid connect authorize scope sur openid email

Hébergé par nous ? Ce plugin est disponible sur nos offres Business et Enterprise. OAuth 2.0 & OpenID Connect Support | Discourse - Civilized Discussion

---

1. token ou charge utile userinfo ↩︎

2. du token ou de la charge utile userinfo ↩︎