# Oauth2-basic plugin and pkce

**URL:** <https://meta.discourse.org/t/oauth2-basic-plugin-and-pkce/161386>\
**Category:** SSO\
**Tags:** oauth2\
**Created:** [August 19, 2020, 3:40pm UTC](https://meta.discourse.org/t/oauth2-basic-plugin-and-pkce/161386 "2020-08-19T15:40:15Z")\
**Posts on this page:** 1\
**Showing post:** 2

<div class="post-metadata">

**Author:** ![supermathie](https://sea3.discourse-cdn.com/meta/user_avatar/meta.discourse.org/supermathie/32/507518_2.png) [@supermathie](https://meta.discourse.org/u/supermathie)\
**Post date:** [July 11, 2023, 2:14pm UTC](https://meta.discourse.org/t/oauth2-basic-plugin-and-pkce/161386/2 "2023-07-11T14:14:48Z")

</div>

Bumping this as a community I assist is requesting support for PKCE.

Prior to being asked about it, I hadn’t yet seen anything about this, but looking through [documentation for it](https://auth0.com/docs/get-started/authentication-and-authorization-flow/authorization-code-flow-with-proof-key-for-code-exchange-pkce) it seems the primary driver for this is native apps and SPAs:

> Native apps
> 
> - Cannot securely store a Client Secret. Decompiling the app will reveal the Client Secret, which is bound to the app and is the same for all users and devices
> - May make use of a custom URL scheme to capture redirects (e.g., MyApp://) potentially allowing malicious applications to receive an Authorization Code from your Authorization Server
> 
> Single-page apps
> 
> - Cannot securely store a Client Secret because their entire source is available to the browser

Neither of which is applicable to this situation; it’s the Discourse server that holds the secret.

![Animated GIF](https://media3.giphy.com/media/4YY4DnqeUDBXNTcYMu/giphy.webp?cid=04a688a2osk0shtq25gc5kcl1ahgejxekpj08rh8ohaiejta&ep=v1_gifs_search&rid=giphy.webp&ct=g)

---

_[View the full topic](https://meta.discourse.org/t/oauth2-basic-plugin-and-pkce/161386)._