Clancey
Feature Request - Implement PKCE
Feature Request - Implement PKCE.
PKCE is standard for public clients, a mobile app is considered a public client; therefore a client secret is no longer secure. PKCE fixes this, the simple_auth library is great, but it would be much appreciated if you could implement PKCE.
Tip: Identity Server 4 has PKCE support out of the box, so it's easy to test against.
So while this is not advertised. It does work. AzureAD, and GoogleAuth both work this way. Notice the client secret is not required. If there is a standard/open OAuth Server you know of I can modify the sample to show it off. Or maybe the OAuthApi needs client secret to be optional.
Sorry for not getting back to you sooner, to mitigate public clients (in this case mobile apps) from the threat of having the authorisation code intercepted. The technique (PKCE) involves the client first creating a secret, and then using that secret again when exchanging the authorisation code for an access token. This way if the code is intercepted, it will not be useful since the token request relies on the initial secret.
Some useful links:
https://oauth.net/2/pkce/ https://aaronparecki.com/oauth-2-simplified/#mobile-apps https://tools.ietf.org/html/rfc7636
I have tried this playground with Okta, but this might work, it supports PKCE: https://www.oauth.com/playground/authorization-code-with-pkce.html
For Google, they also support PKCE as shown in Step 1: https://developers.google.com/identity/protocols/OAuth2InstalledApp
Identity Server 4 supports PKCE, it runs on .NET Core, and you can easily fire it up using Docker. https://identityserver4.readthedocs.io/en/release/
Oddly enough, many mobile apps out there only use client secrets, that client secret is embedded into the mobile app itself, once you decompile, you can search around and find it, write a little app to pretend you are their (the original/official) mobile app, and try and steal credentials. We all seem to take this for granted, which is why PKCE exists to ensure this tampering doesn't happen.
For me, I wouldn't want to provide customers/clients a mobile app that doesn't utilise PKCE behind the scenes.
Is there a plan for this feature? I use Ionic, AppAuth-JS (Auth Code + PKCE), and IdentityServer 4. Looking to move to Flutter for new project but need the PKCE support (customer requirement).
It sure is needed, I would classify any public client (includes mobile apps) as secure whatsoever if PKCE is not in the flow. Without PKCE we can use obfuscation and code hardening techniques to make secrets harder to steal, but not impossible. If the client secret can be stolen, then it can be used by anyone to complete an authorisation code exchange.
An IdentityServer provider implementation (with PKCE) would be a great addition.
If anyone wants to try this, I've added it to a PR. It is optional, and must be turned on with the usePkce flag when creating an OAuthApi.
