Do I need PKCE?
Fantastic question. This gets to the heart of OAuth2/OIDC security—and where web security, browser limitations, and OAuth’s different client types matter.
1. Public vs. Confidential Clients
-
Confidential clients (like backend servers) can keep secrets—they don’t expose them to the user/browser.
-
Public clients (like browser SPAs, native mobile apps) can never keep a real secret—anything bundled in JS, HTML, or shipped to a device is fundamentally accessible to a user or attacker.
2. What do real IDPs do?
-
Browser-based SPAs (e.g. React, Vue, plain JS, Flask-with-templates) are always “public clients.”
-
They either don’t use a secret, or use PKCE (“Proof Key for Code Exchange”) instead of a secret, to avoid leaking secrets in public code.
-
Most modern OAuth providers (Auth0, Google, Okta, Microsoft) require PKCE for SPAs and ignore the client secret in this context.
-
-
Backend (server-side) clients (e.g. your Flask API gateway if it runs as a real server, not just a static file server) can keep secrets and are “confidential clients.” They can safely send a
client_secretin the/tokenexchange.
3. For Your Setup (MVP):
-
If your Flask API Gateway is acting as a true backend (not just serving JS to the browser) and handles the code/token exchange server-to-server, then using a client secret is okay. The secret is NOT exposed to the browser.
-
If you were to write a pure JS SPA (React, Vue, etc.), you should not use a client secret—only PKCE.
4. How to Know Which to Use?
-
If your Flask app runs on the server and users only interact via browser forms that POST to Flask endpoints:
✔️ Safe to useclient_secretin server-to-server calls. -
If you ever expose the secret to JS in the browser:
❌ Do not do this! Use PKCE and register as a public client.
5. Summary Table
| App Type | Uses client_secret | Uses PKCE | Example |
|---|---|---|---|
| Backend Flask API | Yes | No | Your current approach |
| JS SPA (browser) | No | Yes* | React/Vue SPA |
| Mobile App | No | Yes* | iOS/Android native |
* “Yes” = recommended/best practice.
6. TL;DR for Your Project
-
You are OK to use
client_secretbecause your Flask gateway is not browser code. -
Don’t ever leak that secret to the client (browser-side JS).
Want to go full Auth0/Okta-style?
-
Add PKCE to support “public clients” in the future.
-
For now, with Flask as backend, this is standard and safe.
Let me know if you want to see a PKCE flow or keep going with the server-based setup!
Comments
Post a Comment