Redirect URI Validation#

When a Client has the Authorization Code or Implicit Client Capabilities , it must also provide one or more Redirect URIs for applications to finalize the authorization flow.

By default, the Curity Identity Server conforms to the OAuth and OpenID Connect specifications, so normally, it is not necessary to change how the Redirect URI is validated.

However, since some applications require more flexibility than is possible when following the specification strictly, the Curity Identity Server makes it possible to use Redirect URI Validation Policies .

This can be very useful during testing, for example.

Redirect URI purpose#

The flows that use the front channel rely on browser redirects to report a result from the Curity Identity Server back to the client, for example the code flow uses a redirect to return the authorization code, and the implicit or hybrid flows return tokens through the redirect URI.

For this, a client is configured with one or more allowed redirect URI’s that the Curity Identity Server can use. A client can, or sometimes must, provide the redirect URI in a request.

When a redirect URI is received, it is validated against a client’s preconfigured (or a dynamically registered client’s pre-registered) allowed redirect URIs. An exact match is always accepted, but some validation rules may be explicitly circumvented under specific conditions.

Configuring a Validation Policy#

To configure a specific Redirect URI Validation Policy for a client, make sure to first create one or more Redirect URI Validation Policies in the Token Profile.