Migrate from Node 12 and 16 to Node 18

Long-term support (LTS) for Node.js 12 and 16 ended in 2023, which means the Node.js development team no longer back-ports critical security fixes to these versions. Running with Node 12 or 16 runtimes could expose your extensibility code to security vulnerabilities.

Node 18 extensibility runtime is generally available (GA) across our entire suite of extensibility offerings. This includes Actions, Rules, Hooks, Database Scripts, and Custom Social Connections. We strongly encourage everyone to update to Node 18 as soon as possible to adhere to best code security practices.

If you are using a discontinued extensibility runtime, we recommend taking the review of your Rules and Hooks implementation as an opportunity for migrating them to (Node 18) Actions. Determine which Rules and Hooks you can migrate to Actions by visiting Actions Limitations. To learn more about migrating your Rules and Hooks to Actions, see Migrate to Actions.

Use the Management API to identify a complete list of social connections that a Node runtime version change may impact. In particular, all potentially impacted social connections, either explicitly created as a custom social connection or initially added through the Marketplace, have the strategy attribute with a value of either oauth1 or oauth2.

You can then paginate through all the existing custom social connections in a given tenant using the GET connections Management API endpoint. For example, the following query options returns the names and identifiers of up to 100 custom social connections:

/api/v2/connections?strategy=oauth1&strategy=oauth2&include_totals=true&fields=name&per_page=100

The Auth0 Dashboard does not allow updating the scripts for custom social connections added through the Marketplace. If a script change is required to be compatible with Node 18, you must use the Management API.

To create a new custom Action with Node 18 through the Auth0 Dashboard:

1. Navigate to Auth0 Dashboard > Actions > Library.

2. Select Create Action > Build from scratch.

3. In the Runtime* field, select Node 18 (Recommended).

4. Write your custom Actions in Node 18, test, and deploy when ready.

   

You can individually upgrade existing custom Actions built on Node 12 or 16 to Node 18 and revert to the previous version using the older runtime. Upgrade Actions to Node 18 by creating and deploying a new version of the existing implementation with any required changes and set to use Node 18 as the runtime.

The runtime used for the remaining (non-Actions) extensibility offerings is defined globally at the tenant's advanced settings level. Changing this setting impacts the following functionality at the same time:

• rules

• hooks

• custom database scripts

• custom social connection scripts

To change the tenant extensibility runtime setting in the Auth0 Dashboard:

1. Navigate to Dashboard > Settings > Advanced.

2. Scroll to the Extensibility section.

3. For Runtime, select Node 18.

Given that this is a global setting that impacts multiple extensibility features simultaneously, we recommend that you perform this step in your development tenant first, complete testing of all applicable extensibility features, and proceed to your production tenant only when you see no issues in development.

Specifically for Custom DB scripts you can follow the steps as explained on this page to individually verify a script against a specific runtime version before proceeding to change the global runtime version.

The Node 12 extensibility runtime supports using specific npm modules without explicitly requiring them in the extensibility code. Starting with Node 16 runtime, we removed support for this type of usage for the following modules:

• _

• async

• Auth0

• azure_storage

• bcrypt

• crypto

• couchbase

• cql

• ip

• jwt

• Knex

• mongo

• mysql

• mysql_pool

• ObjectID

• pbkdf2

• pg

• postgres

• Pubnub

• q

• querystring

• sqlserver

• uuid

• xml2js

• xmldom

• xpath

• xtend

If you still have extensibility running on Node 12, consider the above when updating the code directly to Node 18. Before using a module, you must ensure that it is explicitly required.

In the context of Rules, Custom Database Connections, and Custom Social Connections, you must explicitly require a version of the module that is listed as available for Node 18.

In Hooks and Actions, you must add the intended target version as an explicit dependency before requiring the module.

We removed support for the specified versions of the modules listed below for the Node 18 runtime from Can I Require. This change impacts the extensibility code associated with Rules, Custom Database Connection Scripts, and Custom Social Connection Scripts.

Node.js 18 requires secure renegotiation (RFC 5746) for TLS connections by default, a consequence of the requirement being introduced in the underlying OpenSSL dependency.

If your extensibility code performs external network calls, the target servers must support secure renegotiation, or otherwise, the requests will fail, and you will receive an error similar to:

Error: write EPROTO C0BAF076:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:922:

Given this security-related change, we recommend that you ensure that all target servers are updated to support secure renegotiation. If the servers in question are third-party servers that are not under your control, you can evaluate the possibility of opting into the previous behavior.

For example, for the axios library, the following code snippet illustrates how to opt-in to the legacy behavior:

const axios = require('axios');
const https = require('https');
const crypto = require('crypto');

axios.get(
  'https://[LEGACY_SERVER]', 
  {
    httpsAgent: new https.Agent(
      {
        secureOptions: crypto.constants.SSL_OP_LEGACY_SERVER_CONNECT
      }
    )
  })