Eu acho que o que você está descrevendo aqui é o "Fluxo Implícito" do OpenID Connect, que funciona sem comunicação de servidor para servidor, e, portanto, não precisa de um segredo compartilhado. Em vez disso, todas as informações são transmitidas através dos redirecionamentos HTTP, e o ID token é criptograficamente verificado usando as chaves públicas do Documento de Descoberta.
Tudo bem, e acho que é uma solicitação de recurso válida. Mas é um sistema muito diferente do nosso plugin atual, que usa o fluxo de código de autorização. Este fluxo usa comunicação de servidor para servidor com um segredo compartilhado, e, portanto, nenhuma verificação criptográfica do id_token é necessária. Isso é mais simples em alguns aspectos, mas mais complexo em outros.
Importante: não podemos simplesmente alterar a implementação padrão no plugin. Sites que usam o fluxo de código de autorização precisam continuar usando-o. Pelo que me lembro, muitos provedores de identidade nem sequer suportam o Fluxo Implícito.
Então, acho que há dois caminhos a seguir aqui:
-
Adicionamos suporte para o "fluxo implícito" no plugin OIDC, mas o tornamos algo opcional. Acho improvável que aceitemos um PR que introduza a gema openid-connect como dependência do Discourse core, portanto, ele precisaria ser implementado dentro de nossa estratégia atual.
O plugin discourse-lti (integração de ferramentas de aprendizado) pode ser uma fonte útil de inspiração, porque o protocolo LTI é baseado no fluxo implícito OIDC. A lógica de decodificação do id_token está aqui
ou alternativamente
-
Você constrói o fluxo implícito como um plugin totalmente novo. Neste caso, você teria a liberdade de fazer o que quisesse em termos de implementação (mas também teria que mantê-lo sozinho)