Redirect-URIs absichern
Erfahren Sie, warum die Validierung von Redirect-URIs der Dreh- und Angelpunkt der OAuth2-Sicherheit ist und wie Sie Open-Redirector- und Code-Interception-Angriffe verhindern.
Redirect-URIs absichern ist eine kostenlose OAuth2 & OpenID Connect Deep Dive-Lektion auf CoddyKit. Dies ist Lektion 4 von 4. Du kannst die komplette Lektion unten kostenlos lesen – dann übst du sie direkt im Browser mit einem integrierten Code-Editor und einem KI-Tutor rund um die Uhr. Sie ist Teil des OAuth2 & OpenID Connect Deep Dive-Lernpfads, und dein Fortschritt wird über Web und CoddyKit-App synchronisiert. Der OAuth2 & OpenID Connect Deep Dive-Kurs umfasst insgesamt 4 Lektionen.
Teile dieser Lektion wurden noch nicht übersetzt und werden auf Englisch angezeigt.
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.
Häufig gestellte Fragen
Ist die Lektion „Redirect-URIs absichern“ kostenlos?
Ja — der vollständige Text von „Redirect-URIs absichern“ ist hier im Web kostenlos zu lesen. Um sie interaktiv zu üben (integrierter Code-Editor und 24/7 KI-Tutor) und den Rest des OAuth2 & OpenID Connect Deep Dive-Kurses freizuschalten, upgrade auf CoddyKit PRO. Der OAuth2 & OpenID Connect Deep Dive-Kurs umfasst insgesamt 4 Lektionen.
Was lerne ich in „Redirect-URIs absichern“?
Erfahren Sie, warum die Validierung von Redirect-URIs der Dreh- und Angelpunkt der OAuth2-Sicherheit ist und wie Sie Open-Redirector- und Code-Interception-Angriffe verhindern. Du übst OAuth2 & OpenID Connect Deep Dive mit praktischem Code, den du direkt im Browser ausführst, und ein 24/7 KI-Tutor beantwortet deine Fragen während du die Lektion bearbeitest.
Brauche ich Erfahrung, um OAuth2 & OpenID Connect Deep Dive zu starten?
Keine Vorkenntnisse erforderlich. OAuth2 & OpenID Connect Deep Dive auf CoddyKit ist für Anfänger bis fortgeschrittene Lernende strukturiert, sodass du hier starten oder von Anfang an beginnen und in deinem eigenen Tempo voranschreiten kannst. Dies ist Lektion 4 von 4.
Wie lange dauert die Lektion „Redirect-URIs absichern“?
Die meisten CoddyKit-Lektionen dauern etwa 5–10 Minuten. Jede ist kompakt und interaktiv, sodass du stetig Fortschritte machst und genau dort weitermachst, wo du aufgehört hast – im Web und in der App.
Kann ich in dieser OAuth2 & OpenID Connect Deep Dive-Lektion Code schreiben und ausführen?
Ja. Jede OAuth2 & OpenID Connect Deep Dive-Lektion enthält einen integrierten Code-Editor, sodass du echten Code direkt in deinem Browser schreibst und ausführst und sofort KI-Feedback erhältst — ohne lokale Einrichtung erforderlich.
Alle Lektionen in diesem Kurs
- Token-Sicherheit (Access/Refresh)
- State-Parameter und CSRF
- Best Practices für Grant Types
- Redirect-URIs absichern