# OpenID Connect Plugin Refactor (OIDC Implicit Flow)

**URL:** https://meta.discourse.org/t/openid-connect-plugin-refactor-oidc-implicit-flow/386884
**Category:** Development
**Created:** [October 28, 2025, 12:19am UTC](https://meta.discourse.org/t/openid-connect-plugin-refactor-oidc-implicit-flow/386884 "2025-10-28T00:19:52Z")
**Posts on this page:** 1
**Showing post:** 3

<div class="post-metadata">

### Author: ![david](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/david/32/157490_2.png) [@david](https://meta.discourse.org/u/david)
#### Post date: [October 29, 2025, 1:19pm UTC](https://meta.discourse.org/t/openid-connect-plugin-refactor-oidc-implicit-flow/386884/3 "2025-10-29T13:19:37Z")

</div>

Also worth noting that the OIDC “Implicit Flow” does increase the surface area for CSRF attacks and token exposure:

> **[Implicit flow vs. Authorization code flow: Why implicit flow is dead? · Logto...](https://blog.logto.io/implicit-flow-is-dead)**
>
> Why is there an "Authorization code flow" in OAuth 2.0 when we already have the "Implicit flow"? Let's dive into the details of these two grant types and find out why you should avoid using the implicit flow.

I think it can still make sense for some situations. But it seems like the Authorization Code flow (Discourse’s default) with PKCE (optional in Discourse) is the most-recommended way to use OIDC.

So it may be worth reconsidering this statement:

> [@justinm](#):
>
> I’m looking to improve our security posture, and part of that means that we need to avoid using secret credentials

Is switching to the OIDC implicit flow, and therefore transmitting all your user information via the client, really an improved security posture? 🤔

---

_[View the full topic](https://meta.discourse.org/t/openid-connect-plugin-refactor-oidc-implicit-flow/386884)._