# Refatoração do Plugin OpenID Connect

**URL:** <https://meta.discourse.org/t/openid-connect-plugin-refactor-oidc-implicit-flow/386884>\
**Category:** Development\
**Created:** [Outubro 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:** 4

<div class="post-metadata">

**Author:** ![justinm](https://avatars.discourse-cdn.com/v4/letter/j/47e85d/32.png) [@justinm](https://meta.discourse.org/u/justinm)\
**Post date:** [Outubro 31, 2025, 1:17am UTC](https://meta.discourse.org/t/openid-connect-plugin-refactor-oidc-implicit-flow/386884/4 "2025-10-31T01:17:19Z")

</div>

Obrigado pela resposta detalhada!

> Acho que ainda pode fazer sentido em algumas situações. Mas parece que o fluxo de Código de Autorização (o padrão do Discourse) com PKCE (opcional no Discourse) é a maneira mais recomendada de usar OIDC.

Isso é muito interessante - eu não tinha compreendido totalmente o PKCE até agora. Com base na minha leitura da [documentação do Auth0](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-pkce), parece que (em certas configurações) este fluxo tem as vantagens do fluxo implícito (sem segredo do cliente) sem nenhuma das desvantagens.

> **[Get Rid Of Client Secrets With OAuth Authorization Code PKCE Flow | Xebia](https://xebia.com/blog/get-rid-of-client-secrets-with-oauth-authorization-code-pkce-flow/)**
>
> In this article, we'll dive into the OAuth 2.0 Proof Key for Code Exchange (PKCE) flow, an extension of the Authorization Code flow that helps prevent CSRF

Será que isso é algo que pode ser feito em vez disso? Parece que é tão simples quanto remover o parâmetro `client_secret` do endpoint `/token`.

E, finalmente, minha principal preocupação é apenas eliminar a necessidade de um segredo do cliente 🙂

---

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