Skip to main content

Managing multiple environments (prod/staging/dev)

info

Advanced topic: This is an advanced topic, if you have questions about any of this, please reach out to Authress Developer Support, so one of our Authress Security experts can help clarify.

Throughout the development life-cycle of your platform and product applications, you'll have multiple environments. Common ones include Production and Staging, although there can be many more. This article answers the question of how best to architect your Authress account to better manage these different environments.

The recommended number of accounts is:

Background​

The optimal solution encourages having three Authress CIAM accounts. These accounts are usually:

  • Production + Shared Account Management (SSO configuration, Consolidated Billing)
  • Non-Production - Usually used by automation to validate Production changes before deploying them to production.
  • Sandbox - Used for manual exploring, testing SDKs, and development using the REST APIs.

There are many reasons for this:

  • Physical separation - separate accounts creates segregated blast areas. You can better secure and limit access to your production account.
  • Audit trails, streams, and logging - separate accounts means it is easy to query your exported Audit Stream
  • Replicated deployments - This makes it easy to create and deploy the exact same security infrastructure you created in a non-production environment. This can be easily achieved using one of our CI/CD OIDC integrations.

Caveats​

  • Multiple Authress Account IDs - since every account gets a unique Authress account ID. Having multiple increases complexity in your configuration.
  • Custom Domain - For higher reliability, Authress supports running your domain via DNS subdomain. Every account must have a different DNS. With multiple accounts, along with different Authress account IDs, the url for each account's API has to be different.
  • UX - Access and usage for your Developers and Support Engineers when using Authress is easier and simpler when there is only one account.

Use Authress Local for local development​

Authress Local provides a development container that runs the Authress API in a box. You can use Authress Local to easily test new APIs and run your existing environment without needing to connect to a live Authress account.

Using CI/CD​

Authress recommends using GitHub, GitLab, or another automated CI/CD platform to create and managed your user roles, applications, connections, audit trail, and all other reusable resources as much as possible. This enables easy and replicable deployment. When using multiple accounts is this a strong recommendation to avoid problems where resources exist in one environment but not a second one.

Reuse your production user identities​

When one of your users that logs in through different Authress accounts, they will get different IDs. Since there is only one user there should only be one userId. Multiple accounts creates multiple user IDs.

To solve this problem, Authress recommends to only use Authentication from one account, in this case the production one. For instance, when building a new application, configure the login for that application to be the production environment Authress account. This way the userIds are consistent across multiple application environments. You can enable your non-production Authress accounts to Trust Authress JWTs from any other Authress account. To set this up, review the OIDC Trusted Identities guide.

Reserve Non-Production for testing Authress configuration​

Where possible use the production environment account, for instance during log in. For authorization checks, since you'll be creating access records for non-production in the non-production account all API based access will use the non-production version.

Last updated on