# Require exact redirect matching and PKCE in OAuth authorization-code flows > OAuth authorization-code flows need exact redirect URI matching and correctly enforced PKCE. Treat both as testable protocol controls across every client and authorization server. - Canonical URL: https://update.dsesecurity.com/updates/oauth-exact-redirect-matching-and-pkce/ - Publisher: Detection Systems & Engineering (DSE Security) - Author: DSE Security Editorial Team - Published: 2026-08-25T21:34:05+00:00 - Modified: 2026-08-26T13:27:47+00:00 - Last reviewed by DSE: 2026-08-25 - Resource type: Guide - DSE priority: Important - Topics: Cybersecurity, IT, Microsoft 365 & Identity - Reading time: 3 minutes ## What you need to know OAuth authorization-code flows need exact redirect URI matching and correctly enforced PKCE. Treat both as testable protocol controls across every client and authorization server. ## Potentially affected Organizations operating, developing, integrating, or procuring OAuth 2.0 clients and authorization servers that use browser redirects and the authorization-code grant. ## DSE recommendation Inventory every OAuth redirect flow, enforce exact registered URI comparison, require correctly bound PKCE where applicable, and test rejection paths rather than accepting a successful login as proof. ## Article Bottom line: an OAuth login that succeeds does not prove the authorization-code flow is safely bound to the intended client. Exact redirect URI comparison and correctly enforced Proof Key for Code Exchange (PKCE) close different substitution and code-injection paths, and both need negative testing. ## Source fact: what the OAuth security BCP requires [RFC 9700](https://www.rfc-editor.org/rfc/rfc9700.html), published as an Internet Best Current Practice in January 2025, updates OAuth 2.0 security guidance using experience with deployed systems. For redirect-based flows, it says authorization servers must compare a requested redirect URI with the pre-registered value using exact string matching, except for the permitted handling of localhost port numbers for native applications. It also says clients and authorization servers must not expose open redirectors that forward a browser to an arbitrary URI from a parameter. For authorization-code flows, the RFC requires public clients to use PKCE and recommends it for confidential clients. Authorization servers must support PKCE, enforce the submitted code verifier when a challenge was present, and prevent downgrade behavior. The RFC identifies S256 as the current challenge method that does not expose the verifier in the authorization request. A PKCE challenge or permitted OpenID Connect nonce must be transaction-specific and securely bound to the client and user agent that started the transaction. ## What the source does not establish Exact redirect matching and PKCE do not prove the client, browser, authorization server, resource server, or registered application is trustworthy. They do not correct excessive scopes, missing audience checks, insecure refresh-token handling, compromised endpoints, malicious app registration, or authorization decisions made after token issuance. The RFC defines protocol practice, not a product certification. Provider behavior, native-app redirect mechanisms, reverse proxies, software libraries, and migration constraints must be checked for the exact implementation. Changing redirect registration or PKCE enforcement can interrupt production clients if their real behavior is not known. ## Applicability questions - Which clients use authorization code, implicit, device, client-credentials, or another flow? - What exact redirect URI does each deployed version send, and where is it registered? - Are wildcard, pattern, alternate-scheme, proxy-rewritten, or environment-shared redirects accepted anywhere? - Does every public client create a fresh high-entropy verifier and use S256 for each transaction? - Does the authorization server reject a missing, altered, reused, or incorrectly bound verifier? - Which legacy libraries or brokers would fail if the current BCP were enforced? ## DSE recommendation: test the complete redirect and code binding The following steps are DSE recommendations based on the cited source. Build a register of authorization servers, client identifiers, owners, client types, flows, registered redirect URIs, real redirect URIs, PKCE methods, libraries, and production dependencies. Confirm those values from configuration and observed transactions rather than an architecture diagram alone. For each authorization-code client, test the approved exact redirect and then deliberately change the scheme, host, port where no exception applies, path, case, encoding, query, and suffix. The authorization server should reject every unregistered value. Test client and server endpoints for open-redirect behavior. Exercise PKCE with the correct verifier, an incorrect verifier, a missing verifier, a reused verifier, a downgraded challenge method, and a token request that supplies a verifier when no challenge began the transaction. Move incompatible clients through an owned migration rather than leaving a broad exception. Record the business dependency, affected versions, compensating restrictions, deadline, and retirement evidence. Coordinate changes across application, identity, API, and monitoring owners, with rollback that does not silently restore unsafe matching. ## Verification and evidence Retain the client register, authorization-server configuration, registered redirect export, library and version inventory, redacted protocol traces, negative-test results, change approvals, exceptions, and production monitoring. Evidence should show both the accepted transaction and the rejected mutations without preserving usable authorization codes, tokens, client secrets, or PKCE verifiers. ## Official references - [RFC 9700 — Best Current Practice for OAuth 2.0 Security](https://www.rfc-editor.org/rfc/rfc9700.html) — Internet Engineering Task Force; published January 2025 ## Primary reference - Name: RFC 9700 — Best Current Practice for OAuth 2.0 Security - Authority: www.rfc-editor.org - URL: https://www.rfc-editor.org/rfc/rfc9700.html - Source publication date: Not stated by the source ## Citation and use Preferred citation: “Require exact redirect matching and PKCE in OAuth authorization-code flows,” DSE Security, https://update.dsesecurity.com/updates/oauth-exact-redirect-matching-and-pkce/ Publishing principles: https://update.dsesecurity.com/updates/dse-updates-editorial-methodology/ Usage and citation policy: https://update.dsesecurity.com/usage/ Copyright © 2026 Detection Systems & Engineering. All rights reserved.