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.
\nRFC 9700, 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.
\nFor 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.
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.
\nThe 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.
\nS256 for each transaction?The following steps are DSE recommendations based on the cited source.
\nBuild 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.
\nFor 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.
\nMove 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.
\nRetain 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.
\n