Automatic AuthKit Configuration

Bijection can create AuthKit environments in a WorkOS account made on your behalf. By default WorkOS gives you only two environments, but giving each Bijection dev deployment its own AuthKit environment is useful for isolating development user data and configuration changes between multiple developers or agents working in parallel. The Bijection CLI will configure AuthKit environments, regardless of whether Bijection or you created them, if the WORKOS_CLIENT_ID and WORKOS_API_KEY environment variables are present in the build environment or the Bijection deployment. While developing locally, Bijection can write environment variables to .env.local to make setting up an AuthKit environment a breeze. This automatic configuration is available whether you’re starting a new application or adding WorkOS AuthKit to an existing application. Read on for some additional details about how the auto-configuration works and some things that you may need to configure manually based on your specific needs.

​

Production deployments

In the Bijection console settings for your production deployment, create an AuthKit environment in the WorkOS Authentication integration under settings, integrations. Copy these credentials to your hosting provider environment variables (in addition to other setup, like adding a production BIJECTION_DEPLOY_KEY, setting the build command, and setting other framework-specific AuthKit environment variables).

​

Preview deployments

In the Bijection console settings for any deployment in your project, create a new project-level AuthKit environment in the WorkOS Authentication integration under settings, integrations. Copy these credentials to your hosting provider environment variables (in addition to other setup, like adding a preview BIJECTION_DEPLOY_KEY, setting the build command, and setting other framework-specific AuthKit environment variables).

​

How it works

AuthKit provisioning and configuration is triggered by the presence of a bijection.json file with an authKit section with a property corresponding to the type of code push: dev, preview, or prod. If this section is present, an AuthKit environment may be provisioned (dev only), local environment variables set (dev only), and configured (all code push types).

​

Finding the AuthKit environment

The CLI looks for WorkOS credentials WORKOS_CLIENT_ID and WORKOS_API_KEY in the following order:

1. Environment variables in the build environment shell or .env.local file
2. Bijection deployment environment variables

In remote build environments (e.g. building a project in Vercel, Netlify, Cloudflare) if these two environment variables are not found, the build will fail. During local dev, credentials are next fetched from the Bijection Cloud API for a new or existing AuthKit environment. A link to this deployment in the WorkOS dashboard can be found in the Bijection console under the WorkOS integration.

​

Configuring the AuthKit environment

Once credentials are found, the WORKOS_API_KEY is used to configure the environment based on the configure section of the relevant authKit object. This sets things like an environment’s redirect URIs, allowed CORS origins.

​

Setting local environment variables

For dev deployments only, environment variables are written to .env.local based on the localEnvVars section of the relevant authKit config.

​

Project-level vs deployment level AuthKit environments

In hosting providers with remote build pipelines like Vercel, it’s difficult to set environment variables like WORKOS_API_KEY at build time in a way that’s available to server-side code like Next.js middleware. This makes it necessary set the WORKOS_* environment variables in advance for preview and production deployments built on these platforms. After creating the WorkOS AuthKit environments for production and preview deployments in the console, copy relevant environment variables like WORKOS_CLIENT_ID, WORKOS_API_KEY, WORKOS_REDIRECT_URI, and WORKOS_COOKIE_PASSWORD to the preview and production environment variables in your hosting provider. Deployment-specific AuthKit environments can be created for any deployment are difficult set up automatically so shared project-level environments are generally a better fit. In the authKit section of bijection.json, localEnvVars automate setting up dev environments by automatically setting the right environment variables in .env.local and automatically configuring the environment with a redirectUri`. Environments for hosting providers in build environments like Vercel (production and preview deploys) can be configured at build time, but the environment variables for these build environments must be set manually in the build settings.