Redirect URI

A Redirect URI (also called a Callback URL or Reply URL) is a pre-registered, whitelisted web address to which an OAuth 2.0 authorization server sends the user-agent (typically a browser) after a user has granted or denied permission to an application. This URI is where the authorization server delivers the authorization code or access token, enabling the client application to proceed with the authentication or data access process. Its primary function is to prevent open redirection attacks by ensuring that sensitive credentials are only sent to a URI the developer has explicitly declared as trustworthy.

During the OAuth flow, the client application initiates the request by specifying the redirect_uri parameter. The authorization server validates this against its list of pre-registered URIs for that client. If it matches, the server redirects the user back to that exact URI, appending the authorization grant as a query parameter or fragment. For example, a common redirect URI for a web application might be https://app.example.com/auth/callback. This precise matching, including the protocol (https), host, port, and path, is a cornerstone of the protocol's security model, preventing tokens from being intercepted by malicious sites.

There are several types of redirect URIs for different application architectures. Web server applications use URIs pointing to their backend server. Single-page applications (SPAs) and native mobile apps often use loopback IP addresses (e.g., http://localhost:8080/callback) or custom URI schemes (e.g., myapp://callback) for local handling. The choice impacts the flow's security; for instance, the PKCE (Proof Key for Code Exchange) extension is strongly recommended for public clients like SPAs and mobile apps to secure the code exchange even when using a local redirect.

Misconfiguration of the redirect URI is a common source of security vulnerabilities. An attacker can exploit an application that allows arbitrary or poorly validated redirect URIs to steal authorization codes or tokens in a redirect URI manipulation attack. Therefore, developers must register full, exact URIs and avoid using wildcards or incomplete paths unless explicitly supported and understood. The validation must be case-sensitive and consider all URI components to ensure a strict match.

A Redirect URI (also called a Callback URL or Reply URL) is a pre-registered endpoint in a client application that receives the authorization code or access token from an OAuth 2.0 authorization server after a user grants consent. This URI is the secure return address where the authorization server sends the user's browser back to the application, completing the critical handoff of credentials. Its exact match against a pre-configured list on the server is a fundamental security control to prevent authorization code interception attacks, such as those where a malicious actor attempts to redirect the flow to a site they control.

During the standard Authorization Code flow, the client application initiates the process by directing the user's browser to the authorization server's /authorize endpoint, including the redirect_uri as a query parameter. After the user authenticates and approves the requested permissions, the authorization server validates that the provided redirect_uri exactly matches one of the URIs registered for that client. Upon successful validation, the server redirects the user's browser back to this URI, appending either an authorization code (for confidential clients) or an access token (for public clients using the Implicit flow, now largely deprecated) in the URL fragment or query string.

The security implications of the Redirect URI are paramount. The requirement for an exact match—including protocol (http vs https), host, port, and path—mitigates open redirection vulnerabilities. For native or mobile applications, special URI schemes like myapp://callback are used. Developers must also protect against CSRF (Cross-Site Request Forgery) by associating a unique, unguessable state parameter with the initial request and verifying it upon receipt at the redirect URI. Mismanagement of redirect URIs, such as using wildcards incorrectly or failing to enforce HTTPS in production, is a common source of security flaws in OAuth implementations.

In practical deployment, the Redirect URI is where the client application's front-end and back-end components often hand off. The front-end receives the code or token from the URL and typically passes it to the application's back-end server. For the Authorization Code flow, the back-end then exchanges the short-lived authorization code for a secure access token and often a refresh token via a direct, server-to-server POST request to the authorization server's /token endpoint, a step that keeps the tokens hidden from the user's browser and enhances security.

A Redirect URI (also called a Callback URL) is a pre-registered, whitelisted web address to which an OpenID Connect (OIDC) or OAuth 2.0 provider, such as a DID Auth service, sends the user back after an authentication or authorization attempt. This mechanism prevents attacks like open redirects by ensuring that sensitive authorization codes or tokens are only delivered to a URI explicitly declared and validated by the Relying Party (RP) or client application during its initial registration with the identity provider.

In a typical DID Auth flow using SIOPv2 (Self-Issued OpenID Provider v2), the Relying Party includes its approved redirect_uri in the Authentication Request. The user's wallet or identity agent, acting as the OpenID Provider, validates that this URI matches one of the client's registered URIs. Upon successful verification, the wallet redirects the user back to this exact URI, appending the authorization response containing the ID Token (a Verifiable Presentation or JWT) in the URL fragment or as a POST response, completing the authentication handshake.

Security best practices mandate that Redirect URIs must use HTTPS in production (with http://localhost allowed for development), be compared using exact string matching, and should not contain wildcards or user-controlled parameters that could facilitate injection attacks. Mismanagement of Redirect URIs is a common vulnerability, so protocols like OAuth 2.0 and frameworks like Solid OIDC enforce strict validation to maintain the integrity of the decentralized authentication process and protect user credentials.