Je pense que ce que vous décrivez ici est le flux implicite d’OpenID Connect, qui fonctionne sans aucune communication serveur à serveur, et n’a donc pas besoin de secret partagé. Au lieu de cela, toutes les informations sont transmises via les redirections HTTP, et le jeton d’identification est vérifié cryptographiquement à l’aide des clés publiques du document de découverte.
C’est bien, et je pense que c’est une demande de fonctionnalité valide. Mais c’est un système très différent de notre plugin actuel, qui utilise le flux de code d’autorisation. Ce flux utilise une communication serveur à serveur avec un secret partagé, et donc aucune vérification cryptographique de l’id_token n’est nécessaire. C’est plus simple à certains égards, mais plus complexe à d’autres.
Important : nous ne pouvons pas simplement modifier l’implémentation par défaut du plugin. Les sites qui utilisent le flux de code d’autorisation doivent continuer à l’utiliser. Je crois me souvenir que de nombreux fournisseurs d’identité ne prennent même pas en charge le flux implicite.
Je pense donc qu’il y a deux voies à suivre ici :
-
Nous ajoutons la prise en charge du “flux implicite” dans le plugin OIDC, mais en tant qu’option opt-in. Je pense qu’il est peu probable que nous acceptions une PR qui introduise la gemme openid-connect comme dépendance de Discourse core, elle devrait donc être implémentée dans notre stratégie actuelle.
Le plugin discourse-lti (intégration d’outils d’apprentissage) peut être une source d’inspiration utile, car le protocole LTI est basé sur le flux implicite OIDC. La logique de décodage de l’id_token se trouve ici.
ou alternativement
- Vous créez le flux implicite en tant que plugin entièrement nouveau. Dans ce cas, vous seriez libre de faire ce que vous voulez en termes d’implémentation (mais vous devriez également le maintenir vous-même).