การรักษาความปลอดภัย URI เปลี่ยนเส้นทาง

After the user authorizes, the authorization server sends the code (or token) back to the client by redirecting the browser to the redirect_uri. If an attacker can influence that URI, they can steal the code.

Redirect URI validation is therefore one of the highest-impact security controls in OAuth2.

The single most important rule: the authorization server must compare the supplied redirect_uri against pre-registered values using exact string matching, not pattern or prefix matching.

Loose matching enables open redirector attacks. If https://app.example.com/* is allowed, an attacker may target a page that bounces to an evil host, smuggling the authorization code out.

Avoid wildcard subdomains and ports. Something like https://*.example.com/cb lets an attacker who controls any subdomain (including user-content subdomains) receive codes.

Redirect URIs must use https, except for native loopback (http://127.0.0.1) during local development. Plain http over the network exposes the code to interception.

Attackers add fragments (#) or extra query parameters to confuse parsers. Normalize and compare the full registered URI, and reject requests whose redirect_uri carries unexpected components.

Native apps often use custom schemes like myapp://callback, but these can be hijacked by another app registering the same scheme. Prefer claimed HTTPS redirects (Universal Links / App Links) which the OS verifies against your domain.

If a redirect_uri was sent in the authorization request, the same value must be sent at the token request and the server must verify they match. This binds the code to the original client and redirect.

Server-side exact-match check, no normalization shortcuts:

Strict redirect validation pairs with PKCE (so a stolen code is useless without the verifier) and the state parameter (to bind the response to the session). Defense in depth keeps codes safe even if one control slips.

Keep the registered redirect list short and reviewed. Remove staging URLs from production clients, audit them regularly, and never let users dynamically add arbitrary redirect URIs.

Securing redirect URIs is foundational:

• Use exact-match registration; avoid wildcards and prefix matching.
• Require HTTPS (loopback excepted) and reject odd fragments/params.
• Re-validate redirect_uri at the token request.
• Combine with PKCE and state for defense in depth.