Custom Database Action Script Environment Best Practices
Auth0 serverless Webtask containers can make use of a wide range of
npm modules not only reduce the overall size of action script code implementation, but also provide access to a wide range of pre-built functionality.
By default, a large list of publicly available
npm modules are supported out-of-the-box. This list has been compiled and vetted for any potential security concerns. If you require an
npm module that is not supported out-of-the-box, then a request can be made via the Auth0 support portal or your Auth0 representative. Auth0 will evaluate your request to determine suitability. There is currently no support in Auth0 for the user of npm modules from private repositories.
Auth0 action scripts support the notion of environment variables, accessed via what is defined as the globally-available
configuration object. The
configuration object should be treated as read-only and should be used for storing sensitive information, such as credentials or API keys for accessing external identity stores. This mitigates having security-sensitive values hardcoded in an action script.
configuration object can also be used to support whatever Software Development Life Cycle (SDLC) best practice strategies you employ by allowing you to define variables that have tenant-specific values. This mitigates hardcoded values in an action script, which may change depending upon which tenant is executing it.
Auth0 serverless Webtask containers are provisioned from a pool that is associated with each Auth0 tenant. Each container instance makes available a global object, which can be accessed across all action scripts that execute within it (the container instance). The global object acts as a global variable that is unique to the container and that can be used to define information—or even functions—that can be used across all action scripts that run in it (the container instance).
This means that the global object can be used to cache expensive resources, as long as those resources are not user-specific. For example, an Access Token for a third-party (e.g., logging) API that provides non user-specific functionality could be stored. Or it could be used to store an Access Token to your own non user-specific API defined in Auth0 and obtained via use of the Client Credentials flow.
Each time a Webtask container is recycled, or for each instantiation of a new Webtask container, the global object it defines is reset. Thus, any declaration of assignment within the global object associated with a container should also include provision for initialization. To provide performance flexibility, serverless Webtask containers are provisioned in Auth0 on an ad-hoc basis and are also subject to various recycle policies. In general, we recommend that you do not consider the life of a global object to be anything more than 20 minutes.
Custom database connection environment checklist
Make sure that your database has the appropriate fields to store user profiles attributes, such as id, nickname, email, and password. See Normalized User Profile for details on Auth0's user profile schema and the expected fields. Also, see Update User Profile Using Your Database for more information.
You can use return errors resulting from your custom database connection for troubleshooting purposes.
user_id) property in the returned user profile will be used by Auth0 to identify the user. If you are using multiple custom database connections, then the id value must be unique across all the custom database connections to avoid user ID collisions. Our recommendation is to prefix the value of id with the connection name (omitting any whitespace). See Identify Users for more information on user IDs.
Latency will be greater compared to Auth0-hosted user stores.
The database or service must be reachable from the Auth0 servers. You will need to configure inbound connections if your store is behind a firewall.