PKCE Becomes Mandatory for OAuth Public Clients as RFC 9700 and OAuth 2.1 Close Authorization Code Interception Risks
The OAuth authorization code grant was designed to avoid exposing user passwords to applications by issuing short-lived codes instead of tokens directly. However, public clients such as native mobile apps and single-page applications cannot securely store a client_secret, leaving intercepted codes vulnerable to exchange for tokens.
PKCE (Proof Key for Code Exchange), defined in RFC 7636, solves this by requiring the client to generate a high-entropy code_verifier (43–128 characters) and send its SHA-256 hash as code_challenge during the initial authorization request. The authorization server stores the challenge and later verifies it against the verifier supplied at the token endpoint.
Why mobile apps cannot rely on client secrets
Server-side applications keep secrets in environment variables, but native Android or iOS apps can be decompiled and browser-based applications expose all source code. Even protected storage like iOS Keychain or Android Keystore can be bypassed on jailbroken or rooted devices, making any embedded secret effectively public.
The attack PKCE was created to stop
Multiple applications can register the same custom URI scheme such as myapp://callback. When the authorization server redirects the code, the operating system may deliver it to a malicious app that quietly declared the same scheme in its manifest. RFC 7636 notes that such code interception attacks have been observed in the wild.
How PKCE works in practice
The client creates a code_verifier using a cryptographically secure random generator, computes the code_challenge as BASE64URL(SHA256(verifier)), and includes it with code_challenge_method=S256. At token exchange the original verifier is sent over a secure channel; the server recomputes the hash and rejects any mismatch with an invalid_grant error.
The plain method offers only limited protection and is deprecated in favor of S256, which is mandatory to implement on servers. Omitting the method parameter defaults to plain, silently weakening security.
Three distinct threats often confused
- Code interception: malicious app steals the real user code via URI scheme collision.
- Code injection: attacker supplies its own code to bind a victim session to the attacker account; PKCE blocks this even for confidential clients.
- Downgrade: server accepts requests without a challenge, disabling verification entirely.
PKCE does not replace other safeguards
The state parameter still protects against CSRF, and nonce in OpenID Connect ensures ID token freshness. RFC 9700 allows relying on PKCE for CSRF protection only after confirming server support. PKCE also does not protect issued access tokens; sender-constrained mechanisms such as DPoP (RFC 9449) or mutual TLS (RFC 8705) address that layer.
Current status in 2025–2026
RFC 9700 (BCP) already requires PKCE for public clients and recommends it for confidential clients. The OAuth 2.1 draft (draft-ietf-oauth-v2-1-15) integrates PKCE into the core flow and removes implicit and ROPC grants. Providers differ in defaults: Auth0 and Okta enforce S256, while Microsoft Entra ID still documents both methods.
Even AI agent authorization frameworks such as the Model Context Protocol are adopting OAuth 2.1 with PKCE for HTTP transports where static secrets are impractical.
Related articles
Fuzzy Logic in Cybersecurity: Reducing Vulnerability Queue by 7.5 Times with CVSS, EPSS and FSTEC Comparison
An information security specialist has developed a fuzzy logic system that prioritizes vulnerabilities far more effectively than traditional scoring methods. The approach uses linguistic variables and membership functions to handle the inherent uncertainty in exploitability and impact assessments. By integrating EPSS probability data with CVSS impact scores and vulnerability age, the model reduces the actionable backlog by a factor of 7.5. The implementation relies on the Mamdani inference algorithm and trapezoidal membership functions to produce smooth, human-interpretable urgency ratings. Detailed coverage checks and rule-base validation ensure no gaps exist in the decision space. Real-world testing on CVE-2025-49113 in Roundcube Webmail demonstrated practical advantages over rigid threshold logic. The method is positioned as a practical enhancement rather than a replacement for existing standards.
VLC Media Player Hit by Two Memory Corruption Flaws Exploitable via Malicious PNG and Rogue RealRTSP Server
Two vulnerabilities have been discovered in the VLC media player that allow out-of-bounds memory access. The issues affect versions from 3.0.0 through 3.0.23. CVE-2026-56711, rated 8.6 on CVSS 4.0, stems from an integer overflow when calculating image buffer sizes in PNG files, enabling attackers to trigger writes beyond allocated memory simply by opening a crafted image or loading it from a playlist. CVE-2026-73324, scored 6.9, resides in the RealRTSP module and permits a malicious server to send an oversized response string that causes reads past the end of a buffer due to a missing null terminator. Both flaws are present in official VideoLAN builds, although some distributions may exclude the RealRTSP component. No special configuration or plugins are required to trigger the issues. Until patched releases appear, users are advised to avoid opening images or playlists from untrusted sources and to refrain from connecting to unknown RealRTSP streams.
September Windows 11 Security Update KB5124008 Breaks Always On VPN Certificate Authentication
The September security update KB5124008 for Windows 11 has introduced a regression that disables Always On VPN connections using certificate-based authentication. The issue affects devices running Windows 11 versions 24H2 and 25H2 that connect to Remote Routing and Access Service (RRAS) and Network Policy Server (NPS) instances on Windows Server 2019. VPN profiles deployed via Microsoft Intune are impacted, with the failure occurring during the certificate negotiation phase of the IPsec connection. Users confirm the problem is reproducible: the VPN works before the patch, stops after installation, and resumes after patch removal and reboot. Microsoft has not yet acknowledged the regression or released a fix, leaving administrators to pause deployment through WSUS or Intune and open support cases with client and NPS logs. A potential workaround involves switching profiles to EAP-TLS, though its reliability remains unconfirmed.
API Token Lifecycle: From Issuance to Revocation and Secure Management
The article provides a comprehensive examination of the full API token lifecycle in browser-based applications, emphasizing that signatures alone cannot prevent token theft. It details risks introduced at issuance, storage, transmission, and revocation stages, including improper OAuth grant types and long-lived tokens. Key recommendations include short-lived access tokens, atomic refresh token rotation, and the use of Authorization Code Flow with PKCE for public clients. Storage advice strongly discourages localStorage and sessionStorage in favor of HttpOnly cookies or a Backend-for-Frontend pattern that keeps real tokens on the server. The piece also covers CSRF protections, rate limiting on authorization endpoints, and the advantages of signed client assertions over static secrets. Overall, it stresses that token security depends on the entire lifecycle architecture rather than cryptographic strength alone.