Securing Redirect URIs
Learn why redirect URI validation is the linchpin of OAuth2 security and how to prevent open redirector and code-interception attacks.
Securing Redirect URIs is a free OAuth2 & OpenID Connect Deep Dive lesson on CoddyKit — lesson 4 of 4. You can read the complete lesson below for free — then practise it hands-on in the browser with a built-in code editor and a 24/7 AI tutor. It is part of the OAuth2 & OpenID Connect Deep Dive learning path, one of 4 lessons in the course, and your progress syncs across the web and the CoddyKit app.
The redirect_uri Is Critical
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.
Exact Matching
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.
Registered: https://app.example.com/callback
Request: https://app.example.com/callback (OK)
Request: https://app.example.com/callback/x (REJECT)Open Redirector Abuse
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.
Wildcards Are Dangerous
Avoid wildcard subdomains and ports. Something like https://*.example.com/cb lets an attacker who controls any subdomain (including user-content subdomains) receive codes.
Always Require HTTPS
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.
Fragments and Query Tricks
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 App Schemes
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.
Validating on Both Requests
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.
POST /token
grant_type=authorization_code
&code=SplxlOBeZ
&redirect_uri=https://app.example.com/callback <-- must equal the one used earlierA Validation Helper
Server-side exact-match check, no normalization shortcuts:
function isAllowed(requested, registeredList) {
return registeredList.includes(requested);
}
// Reject anything not an exact, literal match.Combine With PKCE and State
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.
Operational Tips
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.
Quick Check
Test your redirect URI security knowledge.
Recap
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.
Frequently asked questions
Is the “Securing Redirect URIs” lesson free?
Yes — the full text of “Securing Redirect URIs” is free to read here on the web, and the OAuth2 & OpenID Connect Deep Dive course includes 4 lessons in total. To practise it interactively (a built-in code editor and a 24/7 AI tutor) and unlock the rest of the OAuth2 & OpenID Connect Deep Dive course, upgrade to CoddyKit PRO.
What will I learn in “Securing Redirect URIs”?
Learn why redirect URI validation is the linchpin of OAuth2 security and how to prevent open redirector and code-interception attacks. You practise OAuth2 & OpenID Connect Deep Dive with hands-on code you run directly in the browser, and a 24/7 AI tutor answers your questions as you work through the lesson.
Do I need any experience to start OAuth2 & OpenID Connect Deep Dive?
No prior experience is required. OAuth2 & OpenID Connect Deep Dive on CoddyKit is structured for beginners through advanced learners; this is — lesson 4 of 4, so you can start here or from the beginning and move at your own pace.
How long does the “Securing Redirect URIs” lesson take?
Most CoddyKit lessons take about 5–10 minutes. Each one is bite-sized and interactive, so you make steady progress and pick up exactly where you left off across the web and the app.
Can I write and run code in this OAuth2 & OpenID Connect Deep Dive lesson?
Yes. Every OAuth2 & OpenID Connect Deep Dive lesson includes a built-in code editor, so you write and run real code right in your browser and get instant AI feedback — no local setup required.
All lessons in this course
- Token Security (Access/Refresh)
- State Parameter & CSRF
- Grant Type Best Practices
- Securing Redirect URIs