Configure allowed domains

To secure your client-side Openfort publishable key, set allowed domains for any production application. This security practice prevents arbitrary applications from reusing your Openfort publishable key on their site.

You should always restrict allowed domains for any production application. This step is not necessary for the publishable key you use in staging, development, or local environments.

To configure allowed domains for your app, go to the Openfort dashboard and select your production app from the dropdown in the left sidebar. Then, navigate to Configuration > Security.

Under Allowed Origins, list the domains that use your production publishable key.

Allowed domains format

When listing allowed domains, follow these guidelines:

The protocol https is required.
Trailing paths (for example, /path) are not supported.
Wildcards (*) are only supported as a subdomain, for example *.domain.com. Wildcards like *.com or partial wildcards such as *-something.domain.com are not supported.
Localhost (http://localhost:port) is supported, but the port number must be specified. Listing localhost as an allowed domain for production apps is not recommended. If you must add it temporarily for development, remove it afterward.
Many hosting providers treat https://www.example.com and https://example.com as equivalent. If that applies to your app, add both versions (with and without www) as allowed origins in the dashboard.

Setting allowed domains restricts client-side access to your Openfort publishable key only. Openfort's REST API endpoints that you would query from your backend are gated by your app secret, which should never be exposed on a user's client.

Supporting preview URLs

Many hosting providers (for example, Vercel) support preview deployment URLs to make it easy to test changes:

Generic preview URL patterns

Anyone with a free Netlify account can deploy to URLs like deploy-preview-id--yoursitename.netlify.app.

For security reasons, Openfort does not allow adding domains with generic patterns commonly used for preview deployments to the allowlist, such as:

https://*.netlify.app or https://*.vercel.app
https://*-projectname.netlify.app or https://*-projectname.vercel.app

Any project can deploy to a domain that matches these patterns. If you add such a domain to the allowlist for your production publishable key, any actor could set up an arbitrary deployment with your hosting provider and use your production publishable key within their site.

Project-specific preview URL patterns

To secure your Openfort publishable key on preview deployment URLs, check if your hosting provider allows you to map preview deployments to a stable subdomain that only you control.

For example, only members of your Netlify account can deploy to deploy-preview-42.yoursitename.netlify.app.

This allows you to list https://*.yoursitename.netlify.app under allowed domains, which arbitrary actors cannot deploy to. See instructions to set this up with Vercel or Netlify.

Allowed domains are primarily recommended for production applications. If your preview deployments use a development Openfort publishable key, you can leave Allowed Origins empty to support use of your publishable key in previews without the setup above.

App clients and allowed domains

Within an app client, you can override Allowed origins on your app while still sharing the same user base. To add a client, go to Configuration > App settings > Clients tab, and find the Add app client button. Create a client and add Allowed origins.

Allowed OAuth redirect URLs

You can configure allowed OAuth redirect URLs to restrict where users can be redirected after they log in with an external OAuth provider. This security practice prevents users from being redirected to malicious sites with their authentication token. To configure allowed OAuth redirect URLs, navigate to Configuration > App settings > Advanced on the dashboard. Add the OAuth providers allowed to redirect to after authentication.

The URL must be an exact match for the redirect URL. Query params and trailing slashes cause errors.
The URL must be at a domain listed in allowed domains.
The protocol (https) is required.
Wildcards (*) are not supported.
If no URLs are listed, users can be redirected to any URL.