What breaks when teams use 3-legged OAuth without PKCE?

Without PKCE, intercepted authorization codes can be replayed by an attacker who was not the intended client. That weakens delegated authorization, especially in mobile and single-page applications where redirects are exposed to interception risk. PKCE binds the request and response together so the code is only usable by the client that started the flow.

Why This Matters for Security Teams

Without PKCE, the authorization code in a 3-legged OAuth flow becomes a reusable bearer artifact if it is intercepted before the legitimate client exchanges it. That matters because the threat is not limited to broken encryption or weak passwords. It is a protocol-level trust failure that can turn a successful login into delegated access for the wrong party.

Security teams often underestimate how easily redirect traffic can be observed in mobile apps, embedded browsers, and single-page applications. That is why current guidance treats PKCE as a baseline safeguard rather than an optional enhancement. It complements broader identity governance work described in the NIST Cybersecurity Framework 2.0, where strong authentication and protected session handling are part of resilient access control.

NHI Management Group research shows how often delegated access becomes opaque in practice: the Ultimate Guide to Non-Human Identities reports that 92% of organisations expose NHIs to third parties, and only 20% have formal processes for offboarding and revoking API keys. In practice, many security teams discover OAuth abuse only after token misuse or third-party compromise has already spread through connected systems.

How It Works in Practice

PKCE, short for Proof Key for Code Exchange, binds the authorization request to the later token request using a one-time verifier and a derived challenge. The client starts the flow with a secret value it generated locally. The authorization server stores the challenge, then requires the same client to prove possession of the original verifier when redeeming the code. If an attacker steals the code but not the verifier, the exchange fails.

That design is especially important in public clients that cannot safely store a client secret. Mobile apps and browser-based apps were the original PKCE use cases, but the current best practice is broader: any client that may expose redirects, front-channel parameters, or shared execution environments should use PKCE. This aligns with guidance in the NIST Cybersecurity Framework 2.0 for reducing attack surface in identity-enabled workflows.

Operationally, teams should treat PKCE as one control in a larger OAuth hardening pattern:

• Use PKCE on every authorization code flow, even when the application also has other protections.
• Prefer short-lived authorization codes and short token lifetimes to reduce replay value.
• Validate redirect URIs strictly and avoid permissive wildcard patterns.
• Log code exchange failures and anomalous token redemption attempts for detection.
• Review third-party integrations for OAuth scope sprawl and unnecessary consent grants.

NHIMG research on the Salesloft OAuth token breach shows how token abuse can turn one compromised integration into broad downstream access. PKCE does not stop every OAuth abuse path, but it closes a critical interception gap in the code exchange itself. These controls tend to break down when legacy OAuth clients cannot be updated and the team allows mixed client types to share the same authorization path.

Common Variations and Edge Cases

Tighter OAuth protection often increases implementation overhead, requiring organisations to balance deployment speed against interception resistance. That tradeoff is real, especially in older identity stacks where mobile, web, and partner clients were built against inconsistent assumptions.

There is no universal standard for every edge case yet, but current guidance suggests PKCE should be treated as mandatory for public clients and strongly considered for confidential clients as well. Some teams assume a backend application is safe because it can hold a client secret. That assumption fails when the front channel still exposes the code to browser extensions, logging middleware, reverse proxies, or misrouted redirects.

Another common exception is partner integration. External developers may resist PKCE because their tooling was built around older OAuth libraries. That is not a reason to skip it. It is a reason to phase enforcement, publish clear integration requirements, and monitor for noncompliant clients before they are allowed to reach production. For teams investigating related incidents, the Dropbox Sign breach is a useful reminder that delegated access paths often fail at the integration boundary, not just inside the core application.

In practice, the hardest cases are systems with shared redirect infrastructure, hybrid app architectures, or older SDKs that silently disable PKCE support. Those environments need explicit rollout planning because the protocol is only as strong as the weakest client that uses it.

Related resources from NHI Mgmt Group

• What are the implications of using OAuth tokens in third-party integrations?
• Why is OAuth token management critical in cloud environments?
• How should security teams authenticate AI agents in enterprise environments?
• How should security teams govern AI agents that use OAuth access?