Deployment Automation (B2B)
In addition to adopting best practices for change management and QA, successful customers will also integrate Auth0 collateral management as part of some automated deployment process. As discussed in the Architecture section under SDLC support, you will want to ensure you configure separate Auth0 tenants for development, testing, and production environments, and you will want that configuration to be almost identical for the tenant in each environment. Using deployment automation helps ensure this, so that each environment tenant is configured the same, and you will be less likely to see bugs show up as a result of mismatched configurations between environments.
However you configure deployment automation, we’d recommend you unit test your rules, custom DB scripts, and hooks prior to deployment, and run some integration tests against your tenant post-deployment too. For more details regarding this, see the Quality Assurance guidance provided.
Auth0 provides support for a couple of different options when it comes to the deployment automation approaches you can use, and each can be used in conjunction with the other if desired:
The Auth0 Deploy CLI tooling provides you with an easy-to-use script that can help you integrate with your existing Continuous Integration/Continuous Deployment (CI/CD) pipeline.
If you can’t integrate directly with, or for some reason you don’t have a CI/CD pipeline, then the Auth0 Source Control Extensions can provide an easy-to-set-up basic automation process with very low maintenance.
Each environment may also need some environment-specific configuration--Application Client ID’s and Client Secrets will be different between the Auth0 tenants, for example--so you’re going to want some way of being able to dynamically reference this rather than having hard-coded values. Auth0 provides support for handling environment-specific configuration information through one of the following two approaches:
Use keyword replacement if using the Auth0 Deploy CLI tool
Auth0 allows you to configure variables that are available from within custom extensibility; these can be thought of as environment variables for your Auth0 tenant. Rather than hard code references that change when moving code between development, test, and production environments, you can use a variable name that is configured in the tenant and referenced by the custom extensibility code. This makes it easier for the same custom code to function, without changes, in different tenants because the code can reference variables that will be populated with tenant-specific values at execution time:
For use of variables in Actions, read Write Your First Action to learn how to configure secrets in the editor
For use of variables in Rules, see how to configure values
For use of variables in Hooks, see how to configure secrets in the editor
For use of variables in Custom DB Scripts, see the configuration parameters
It’s a recommended best practice to use variables to contain tenant-specific values as well as any sensitive secrets that should not be exposed in your custom code. If your custom code is deployed in GitHub/Gitlab/Bitbucket/VSTS, then using a tenant-specific variable avoids exposure of sensitive values via your repository.
Project Planning Guide
We provide planning guidance in PDF format that you can download and refer to for details about our recommended strategies.
B2B IAM Project Planning Guide
Multiple Organization Architecture (Multitenancy)
Many B2B platforms implement some form of isolation and/or branding for their customers' organization, and this can add complexity to any Identity and Access Management (IAM) system. If this applies to you, then we recommend you take some time to read through our guidance and best practice advice for this type of environment.