# Configure allowed domains

To secure your client-side Openfort publishable key, restrict where it can be used. Allowed domains and app identifiers prevent arbitrary applications from reusing your publishable key on their own site or app.

:::info
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.
:::

Allowed origins are configured per publishable key. Go to the Openfort dashboard, select your production app from the dropdown in the left sidebar, and navigate to **Configuration** > **Security**. Find the **publishable key** you want to configure.

## Browser (web & mobile web)

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.

For preview deployments using a test publishable key (`pk_test_*`), you can leave **Allowed Origins** empty on that key to use it in previews without the setup below. Production keys (`pk_live_*`) should always have allowed origins set.

### 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.

## Native apps

App clients let you configure specific settings for different consumers and platforms, including mobile apps and Unity games. They restrict your **publishable key** and where it can be used.

To add a native app origin, go to **Account Management** > **Configuration** > **Security** in the [dashboard](https://dashboard.openfort.io/security), and find the **publishable key** you want to configure.

### Allowed app identifiers format

To enforce secure usage of your **publishable key**, configure Openfort to restrict which apps can use your key based on application identifiers. An empty list means all requests are denied. You must configure at least one application identifier to use the React Native SDK, Unity SDK, or Swift SDK.

<MultiOptionDisplay
  options={[
  { id: 'reactnative', label: 'React Native' },
  { id: 'swift', label: 'Swift' },
  { id: 'unity', label: 'Unity' },
]}
/>

<span id="reactnative" className="hidden [&>*]:mb-6!">
  Use the unique value that identifies your app in the Apple App Store or Google Play Store.

  * For iOS apps, this is the [bundleIdentifier](https://docs.expo.dev/versions/latest/config/app/#bundleidentifier).
  * For Android apps, this is the [package](https://docs.expo.dev/versions/latest/config/app/#package).

    :::code-group

    ```json [ios]
    "iOS": {
      "bundleIdentifier": "com.myorg.app"
    }
    ```

    ```json [android]
    "android": {
        "package": "com.myorg.app"
    }
    ```

    :::
</span>

<span id="swift" className="hidden [&>*]:mb-6!">
  Use your project's bundle identifier, which you can find under the **Identity** section of your app's target file. It uses reverse domain format, like `com.myorg.app`.

  #### Apple OAuth Client ID override

  If your application uses Apple as a social login method, you can specify a different client ID depending on which environment your application runs in. To use Apple login on an iOS app, the `Client ID` must be the Apple OAuth `bundleId`. All other platforms require the `Client ID` to be the `Identifier` of the [Sign in with Apple service](https://developer.apple.com/documentation/signinwithapple/configuring-your-environment-for-sign-in-with-apple#Create-a-Services-ID).
</span>

<span id="unity" className="hidden [&>*]:mb-6!">
  Copy your project's bundle identifier, which you can find under the **Identity** section of your app's target file. It uses reverse domain format, like `com.myorg.app`.
</span>

### Allowed URL schemes

To use Openfort's social login flows for Apple or Google, you must register the URL scheme for your application with Openfort, for example `myapp://`.

<MultiOptionDisplay
  options={[
  { id: 'reactnative-origin', label: 'React Native' },
  { id: 'swift-origin', label: 'Swift' },
  { id: 'unity-origin', label: 'Unity' },
]}
/>

<span id="reactnative-origin" className="hidden [&>*]:mb-6!">
  To register your URL scheme, copy your application's URL `scheme` from `app.json` or `app.config.ts` and register it in the app client settings.

  :::info
  For development with Expo Go, enter `exp` as the URL scheme for the Expo Go app.
  :::
</span>

<span id="swift-origin" className="hidden [&>*]:mb-6!">
  First, register your URL scheme in your Xcode project. If you're unsure how, follow [these steps](https://developer.apple.com/documentation/xcode/defining-a-custom-url-scheme-for-your-app#Register-your-URL-scheme). Then, use the URL scheme you registered in the app client settings.

  #### Apple OAuth Client ID override

  If your application uses Apple as a social login method, you can specify a different client ID depending on which environment your application runs in. To use Apple login on an iOS app, the `Client ID` must be the Apple OAuth `bundleId`. All other platforms require the `Client ID` to be the `Identifier` of the [Sign in with Apple service](https://developer.apple.com/documentation/signinwithapple/configuring-your-environment-for-sign-in-with-apple#Create-a-Services-ID).
</span>

<span id="unity-origin" className="hidden [&>*]:mb-6!">
  For non-web platforms, [set up deep linking](https://docs.unity3d.com/Manual/deep-linking.html) with your allowed URL scheme.
</span>

## HttpOnly cookies

HttpOnly cookies are inaccessible to client-side JavaScript, which protects a user's session token from being read or stolen by cross-site scripting (XSS) attacks. They are also sent automatically on same-site requests, so your server can authenticate the user during server-side rendering without the token ever touching client code.

To configure cookie-based sessions and verify the token on your server, see:

* [User sessions](/docs/configuration/user-sessions) — how session tokens, signing, and refresh work.
* [Verify tokens server-side](/docs/products/embedded-wallet/server/access-token) — read the `openfort.session_token` cookie and validate it in your backend.