Securing Your Native/SPA Apps 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.
We strongly encourage you to use PKCE. In fact, we require it for native/SPA apps, as the code for these apps are stored on browsers and devices. Without PKCE, you’d have to include a client secret in those public-facing apps.
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. Express, as an Authorization Server, saves that 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 the Express 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, see: Authorization Code Grant With PKCE.
If you have questions email [email protected].