Protect Capture redirects

To help minimize the chances of an Identity Cloud redirect being hijacked, Akamai has introduced a new API client setting – redirect_uri_allow_list – that helps protect any redirects involving the janraincapture.com/widget/* endpoints. This setting complements other mechanisms already in place to help prevent redirect hijacks.

If you configure the redirect_uri_allow_list setting you can specify the domains that the janraincapture.com/widget/* endpoints can redirect users to. If the allowlist setting is enabled then, any time a request is received by a janraincapture.com/widget/* endpoint, the endpoint validates the domain in the request's request_uri parameter against the allowlist. If the domain is in the list the request is filled and the user is redirected. Otherwise, the request is terminated with an invalid redirect_uri error and the user isn't redirected.

Why would I want to use an allowlist?

Bad actors and their attacks are getting more and more sophisticated and complex. By limiting the redirect URI to specific values, your end users can be protected against such things as phishing or social engineering attacks.

What happens if I don't create the allowlist?

If you don't create the allowlist nothing changes. That means that the janraincapture.com/widget/* endpoints continue to redirect users according to the redirect_uri parameter, without validating that redirect URL against a list of allowed domains. We recommend that you create the allowlist to prevent redirect hijacks.

What if I don’t want to change (or break) anything?

Although we recommend adding the allowlist to your application, the setting is optional. If you prefer to leave things exactly as they are then don't create the allowlist.

I want to use this allowlist. How do I go about doing that?

The redirect_uri_allow_list setting is an API client setting, which you can create either by using Console or by using the Identity Cloud Configuration APIs.

What should I add to the allowlist?

The way you configure your allowlist setting depends largely on whether you use the default janrain.com domain or a custom domain. Here’s a table summarizing the common scenarios:

Scenario	Option
I want to leave things exactly the way they are.	Don’t create the setting. Or, if you’ve already created the setting, delete it.
We use Hosted Login with a default janrain.com domain.	Create the uri_redirect_allow_list setting and leave the value of the setting blank. If you need the ability to redirect users to a non-janrain domain, add that domain to the setting value.
We use Hosted Login with a custom CNAME’d domain.	Create the uri_redirect_allow_list setting and add your domain names to the setting value.
We use the JavaScript SDK.	Create the uri_redirect_allow_list setting and add the domain name for your sign-in page to the setting value.
We use the native authentication APIs.	Create the uri_redirect_allow_list setting and leave the value of the setting blank. The native APIs don't redirect, but you should ensure that other people can't use arbitrary redirects with the widget endpoints.

Is there a way to add this setting to all my login clients?

Yes. If you apply the setting to your application settings then, by default, that setting is inherited by all your clients.

In addition, keep in mind that the allowlist setting can be configured differently on individual login clients. For example, you can set a restrictive allowlist at the application level, and add specific domains for login clients that need them. If you do this, the setting configured at the client level takes priority over the same setting configured at the application level.

Are there any restrictions to the domains I can add to my allowlist?

Yes. The redirect_uri_allow_list includes a few stipulations that you need to be aware of:

You can only enter domain names. Among other things, that means leaving off the HTTP and HTTPS protocols and paths. In other words, use example.com as a setting value. Don’t use https://example.com/index.html as a setting value.

And because you use domain names, that means that an entry such as example.com allows redirection to pages such as https://example.com/index.html, https://example.com/my-page.html, etc. Just something to keep in mind.
You can enter multiple domain names (separated by using commas), but the setting value is limited to 1000 characters. Any characters beyond that limit are ignored.
You can’t use wildcard characters (e.g., example.*) and you can’t use mobile deep links (used to open a specific page in an app).

What if I add the setting and then change my mind?

If you add the setting and then change your mind, just delete the setting. Note that it can take up to 10 minutes before updated settings are available in production.