I think what you’re describing here is the OpenID Connect “Implicit Flow”, which works without any server->server communication, and therefore doesn’t need a shared secret. Instead, all information is transmitted via the HTTP redirects, and the ID token is cryptographically verified using the public keys from the Discovery Document.
That’s fine, and I think it’s a valid feature request. But it’s a very different system to our current plugin, which uses the authorization code flow. This flow uses server->server communication with a shared secret, and therefore no cryptographic verification of the id_token is needed. This is simpler in some ways, but more complex in others.
Importantly: we can’t just change the default implementation in the plugin. Sites which are using the authorization-code flow need to keep using that. IIRC many identity providers don’t even support the Implicit Flow.
So I think there are two paths forward here:
-
We add support for the “implicit flow” in the OIDC plugin, but make it an opt-in thing. I think it’s unlikely we’ll accept a PR which introduce the openid-connect gem as a dependency of Discourse core, so therefore it would need to be implemented within our current strategy.
The discourse-lti (learning tools integration) plugin may be a useful source of inspiration, because the LTI protocol is based on the OIDC implicit flow. The id_token decode logic is here
or alternatively
- You build the implicit flow as a totally new plugin. In this case you’d be free to do whatever you like in terms of implementation (but you’d also have to maintain it yourself)