OAuth 2.0 security with PKCE
Proof Key for Code Exchange (PKCE) mitigates the risks of an OAuth 2.0 attack. Without PKCE, a malicious application running in the same browser as your public client app could compromise the security of your app.
It is good practice to use PKCE for native apps and SPAs, because the code is stored on browsers and devices. Without PKCE, you’d have to include a client secret in those public-facing apps. For enhanced security, you should use PKCE whenever you have the option to use it.
How PKCE works
Your app, with the help of our code, generates a code_verifier (nonce).
When a user make a request, your app creates a hash of that code_verifier as a code_challenge.
ForgeRock, as an authorization server, saves the hash value.
After the hash is confirmed as valid, your app exchanges its authorization code grant for an access token. Your client app, as the bearer, can use the token to access to the user’s resources.
This diagram depicts the authorization code grant flow in detail:
If you’re familiar with OpenID Connect (OIDC) specifications, the web app is the relying party, and ForgeRock is the authorization server.
For more information on PKCE standards, see the following IETF document: Proof key for code exchange by OAuth public clients.
For more information on how ForgeRock implements PKCE for native and SPA apps, refer to Authorization code grant with PKCE.