They often treat PKCE as optional when a client secret exists. That is a mistake because PKCE proves possession of the original authorization request at the token endpoint, which is a different control problem from client authentication. In practice, both controls should be in place.
Why This Matters for Security Teams
PKCE is often misunderstood because teams collapse two separate questions into one: “Is this app really the client?” and “Was this the same authorization request that started the flow?” PKCE answers the second question. That matters even in enterprise deployments where a client secret exists, because a leaked code or intercepted redirect can still be replayed if proof-of-possession is not enforced at the token exchange. This is especially relevant for browser-based, mobile, and embedded clients, where secret storage is weak by design and redirect integrity is harder to trust. Current guidance in the OAuth ecosystem is to treat PKCE as a baseline control, not a fallback. That framing aligns with broader identity guidance in NIST Cybersecurity Framework 2.0, which emphasises access control, protective safeguards, and continuous governance. NHI risk research from Ultimate Guide to NHIs — Why NHI Security Matters Now also shows how often credentials and identity protections are mishandled in real environments. In practice, many security teams encounter OAuth abuse only after a code interception or token theft has already occurred, rather than through intentional testing.How It Works in Practice
PKCE adds a cryptographic binding to the authorization code flow. The client creates a high-entropy verifier, derives a challenge, and sends that challenge with the authorization request. Later, when redeeming the code, the client must present the original verifier. If an attacker steals the code but not the verifier, the token endpoint rejects the exchange. That is why PKCE protects the authorization code itself, while the client secret proves the application’s identity to the authorization server. Both controls can coexist without overlap, and in well-designed enterprise architecture they should. In operational terms, teams should apply PKCE to all public clients and many confidential clients too, especially where redirect handling or proxy layers increase exposure. The implementation also needs to match the surrounding identity stack: NIST Cybersecurity Framework 2.0 is useful for mapping the control to authentication, monitoring, and recovery practices, while Ultimate Guide to NHIs — Why NHI Security Matters Now is a useful reminder that identity failures often cascade once secrets or tokens are exposed. Teams also need to ensure the authorization server enforces exact redirect URI matching, short code lifetimes, and one-time code use. For API-driven and delegated enterprise sign-ins, PKCE should sit alongside strong session controls, scoped consent, and step-up checks where risk changes mid-flow. These controls tend to break down when legacy intermediaries rewrite redirects or when custom app frameworks cache verifier material insecurely because the proof-of-possession chain is no longer intact.Common Variations and Edge Cases
Tighter PKCE enforcement often increases implementation overhead, requiring organisations to balance replay resistance against client compatibility and migration effort. The main edge case is confidential clients that already use mTLS, private_key_jwt, or a strong back-channel trust model. There is no universal standard for this yet, but current guidance suggests PKCE still adds value because it protects against code interception even when client authentication is present. The same logic applies to enterprise single sign-on products that front multiple app types behind one login experience. The most common mistake is assuming “server-side app” automatically means “safe without PKCE.” That assumption fails when a server-rendered app still relies on a browser redirect, a reverse proxy, or a mobile wrapper. Another edge case involves non-browser flows and embedded devices, where client secrets may exist but are still difficult to protect at scale. In those environments, PKCE should be paired with NIST Cybersecurity Framework 2.0-style governance and the identity lifecycle discipline discussed in Ultimate Guide to NHIs — Why NHI Security Matters Now. The practical rule is simple: if the authorization code can cross an untrusted boundary, PKCE belongs in the design, even when a client secret is also in play.Related resources from NHI Mgmt Group
Deepen Your Knowledge
NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
Reviewed and updated by the NHIMG editorial team on June 6, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
