Creo que lo que describes aquí es el flujo implícito de OpenID Connect, que funciona sin comunicación de servidor a servidor y, por lo tanto, no necesita un secreto compartido. En su lugar, toda la información se transmite a través de las redirecciones HTTP, y el ID token se verifica criptográficamente utilizando las claves públicas del Documento de Descubrimiento.
Eso está bien, y creo que es una solicitud de función válida. Pero es un sistema muy diferente a nuestro plugin actual, que utiliza el flujo de código de autorización. Este flujo utiliza comunicación de servidor a servidor con un secreto compartido, y por lo tanto no se necesita ninguna verificación criptográfica del id_token. Esto es más simple en algunos aspectos, pero más complejo en otros.
Importante: no podemos simplemente cambiar la implementación predeterminada en el plugin. Los sitios que utilizan el flujo de código de autorización necesitan seguir utilizándolo. Si mal no recuerdo, muchos proveedores de identidad ni siquiera admiten el Flujo Implícito.
Así que creo que hay dos caminos a seguir aquí:
-
Añadimos soporte para el “flujo implícito” en el plugin OIDC, pero lo convertimos en algo opt-in. Creo que es poco probable que aceptemos una PR que introduzca la gema openid-connect como dependencia de Discourse core, por lo que tendría que implementarse dentro de nuestra estrategia actual.
El plugin discourse-lti (integración de herramientas de aprendizaje) puede ser una fuente útil de inspiración, porque el protocolo LTI se basa en el flujo implícito de OIDC. La lógica de decodificación del id_token está aquí
o alternativamente
-
Construyes el flujo implícito como un plugin totalmente nuevo. En este caso, serías libre de hacer lo que quieras en términos de implementación (pero también tendrías que mantenerlo tú mismo)