An OAuth flow that protects the authorization code with a code verifier and challenge pair. For CLIs, it usually relies on a loopback redirect to bind the sign-in result to the same machine that started the login, which reduces code interception risk.
Expanded Definition
Authorization Code With PKCE is the hardened OAuth 2.0 sign-in pattern used by browser-based apps, CLIs, and native clients when a confidential client secret is not practical. PKCE adds a per-login verifier and challenge so the authorization code is only redeemable by the party that started the flow. The standards basis is defined in the OAuth and PKCE specifications, while implementation details vary across vendors and app types; usage in the industry is still evolving for agentic and machine-to-machine tooling. For identity teams, the key distinction is that PKCE protects the code exchange, not the downstream token lifecycle, so it complements broader controls such as NIST Cybersecurity Framework 2.0 and NHI governance rather than replacing them.
It is commonly used with a loopback redirect on the local machine for CLIs, or with a browser redirect for desktop apps, to keep the login response tied to the initiating session. The most common misapplication is treating PKCE as a full replacement for client authentication, which occurs when teams assume a public client can safely skip redirect validation, token scope limits, and secret rotation.
Examples and Use Cases
Implementing Authorization Code With PKCE rigorously often introduces a small amount of client-side complexity, requiring organisations to weigh stronger code interception resistance against easier deployment of public clients.
- A developer CLI opens the system browser, starts a loopback redirect, and redeems the code only after proving possession of the original verifier.
- A desktop application uses PKCE to avoid embedding a shared secret while still binding the callback to the app session.
- An internal tool authenticates operators through the browser, then exchanges the code securely before requesting scoped API access.
- A platform team pairs PKCE with short-lived tokens and session monitoring to reduce the blast radius of a stolen redirect response.
- A security team documents PKCE as part of the broader identity lifecycle described in the Ultimate Guide to NHIs, especially when the client is an agent or automation runner rather than a human user.
Operationally, the pattern is most valuable when the client cannot safely keep a long-term secret, or when a browser handoff is needed but code replay must still be prevented. That is why PKCE is often paired with browser-based login guidance from the NIST Cybersecurity Framework 2.0 and other identity assurance controls.
Why It Matters in NHI Security
PKCE matters because modern NHI and agent workflows frequently rely on public clients, ephemeral environments, and delegated browser sign-in. If the code exchange is not protected, an attacker who intercepts the authorization code can redeem it before the legitimate client does, turning a simple login into credential theft. That risk becomes more serious when the resulting tokens are reused by automation, CI/CD jobs, or AI agents with broad API access.
This is also where governance matters. NHI programs often fail not at the login screen, but at the point where the signed-in session is allowed to reach secrets, service accounts, or privileged APIs. NHI Mgmt Group research shows that 96% of organisations store secrets outside of secrets managers in vulnerable locations including code, config files, and CI/CD tools, which makes tight authorization flows even more important. The broader exposure patterns documented in the Ultimate Guide to NHIs show why identity hardening cannot stop at token issuance. Organisations typically encounter the weakness only after a stolen code or replayed callback produces an unexpected token grant, at which point Authorization Code With PKCE becomes operationally unavoidable to address.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
OWASP Non-Human Identity Top 10 address the attack and risk surface, while NIST SP 800-63 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-63 | PKCE supports stronger OAuth public-client assurance, aligning with digital identity guidance. | |
| NIST CSF 2.0 | PR.AC-1 | Access control depends on secure authentication and session binding during code exchange. |
| OWASP Non-Human Identity Top 10 | NHI-01 | Public-client OAuth flows can expose NHI tokens if interception protections are weak. |
Use PKCE with redirect validation and short-lived tokens to raise assurance for public clients.
Related resources from NHI Mgmt Group
Deepen Your Knowledge
Reviewed and updated by the NHIMG editorial team on June 5, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
