Redirect URL Registration

11.1

In order to ensure the security of the service, you must require developers register one or more redirect URLs for the application. The authorization server must never redirect to any other location. Registering a New Application covers creating a registration form to allow developers to register redirect URLs for their applications.

If an attacker can manipulate the redirect URL before the user reaches the authorization server, they could cause the server to redirect the user to a malicious server which would send the authorization code to the attacker. For public clients without a client_secret, all that is needed is the client_id and authorization code to obtain an access token. If an attacker can obtain an authorization code, they could then exchange it for an access token for public clients. This is another reason it is important for the authorization server to know whether the application is public or private during application registration.

Valid Redirect URLs

When you build the form to allow developers to register redirect URLs, you should do some basic validation of the URL that they enter.

Registered redirect URLs may contain query string parameters, but must not contain anything in the fragment. The registration server should reject the request if the developer tries to register a redirect URL that contains a fragment.

Note that for native and mobile apps, the platform may allow a developer to register a URL scheme such as myapp:// which can then be used in the redirect URL. This means the authorization server should allow arbitrary URL schemes to be registered in order to support registering redirect URLs for native apps. See Mobile Apps for more information.

Per-Request Customization

Often times a developer will think that they need to be able to use a different redirect URL on each authorization request, and will try to change the query string parameters per request. This is not the intended use of the redirect URL, and should not be allowed by the authorization server. The server should reject any authorization requests with redirect URLs that are not an exact match of a registered URL.

If a client wishes to include request-specific data in the redirect URL, it can instead use the “state” parameter to store data that will be included after the user is redirected. It can either encode the data in the state parameter itself, or use the state parameter as a session ID to store the state on the server.