Protección de las URI de redirección
Aprenda por qué la validación de las URI de redirección es esencial para la seguridad de OAuth2 y cómo prevenir ataques de redirección abierta e interceptación de códigos.
Protección de las URI de redirección es una lección gratuita de OAuth2 & OpenID Connect Deep Dive en CoddyKit. Esta es la lección 4 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de OAuth2 & OpenID Connect Deep Dive, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de OAuth2 & OpenID Connect Deep Dive incluye 4 lecciones en total.
Partes de esta lección aún no han sido traducidas y se muestran en inglés.
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.
Preguntas frecuentes
¿La lección «Protección de las URI de redirección» es gratis?
Sí — el texto completo de «Protección de las URI de redirección» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de OAuth2 & OpenID Connect Deep Dive, actualiza a CoddyKit PRO. El curso de OAuth2 & OpenID Connect Deep Dive incluye 4 lecciones en total.
¿Qué aprenderé en «Protección de las URI de redirección»?
Aprenda por qué la validación de las URI de redirección es esencial para la seguridad de OAuth2 y cómo prevenir ataques de redirección abierta e interceptación de códigos. Practicas OAuth2 & OpenID Connect Deep Dive con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.
¿Necesito experiencia previa para empezar OAuth2 & OpenID Connect Deep Dive?
No se requiere experiencia previa. OAuth2 & OpenID Connect Deep Dive en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 4 de 4.
¿Cuánto tiempo toma la lección «Protección de las URI de redirección»?
La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.
¿Puedo escribir y ejecutar código en esta lección de OAuth2 & OpenID Connect Deep Dive?
Sí. Cada lección de OAuth2 & OpenID Connect Deep Dive incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.
Todas las lecciones de este curso
- Seguridad de tokens (acceso/actualización)
- Parámetro state y CSRF
- Prácticas recomendadas para los tipos de concesión
- Protección de las URI de redirección