Action Coding Guidelines

Follow the guidelines below to write performant, secure, and clear Actions code for a streamlined production environment.

• Use the minimum number of HTTP requests possible and set a reasonable timeout (less than 10 seconds) to avoid accumulated requests during login.

• Use application metadata to filter for specific applications to determine if an Action should be run.

• Ensure that Actions, which provide verification or trigger MFA, cannot be bypassed unintentionally or maliciously.

• Actions should never intentionally throw an error; if processes stop because of an error or condition, use the appropriate api method like api.access.deny().

• Use event.request.hostname for the domain used in Authentication API calls; this could be the default Auth0 tenant domain or a custom domain.

• Check for strict equals === with any incoming or stored data.

• Use a return statement when the Action process should stop.

• Run a code linter, like ESLint, and an analyzer, like Semgrep, to improve code quality and find issues automatically.

• Do not write secrets or sensitive code artifacts in plain text as part of your Actions code. Instead, use the Secrets Manager or leverage your own manager by integrating it within the Actions code.

• Do not transmit unencrypted personally-identifiable information (PII) in plain sight, like in URLs or error messages.

• Always use HTTPS URLs for redirects and API calls.

• AllowList IP addresses when possible.

• Watch for incoming data that can be tampered with (URL parameters, user agent, and so on).

• Catch errors and handle as necessary.

• Use guard clauses and return early if the Action processing should not continue.

• Never log sensitive data, secrets, or PII.

• Stay under the maximum of 256 characters logged per Action.

• Use trusted and maintained packages.

• Check for outstanding CVEs using npm's audit feature or an automated dependency checker connected to a repository.

• Use the latest version of a package when possible.

• Check if an email is verified with event.user.email_verified if it is being used in a sensitive or high-security context.

• Different Connections provide different user profile data; the only guaranteed user profile field is the user_id.

• The token returned by api.redirect.encodeToken is signed but not encrypted, so sensitive data or PII should not be included in the payload.

• The Login Flow runs after a successful login, which includes:

  • SSO (no login form shown)

  • silent authentication (checking a session using prompt=none in the authorization URL)

  • refresh token exchange (no user interaction)

  • RO password grants (credentials gathered from an application and exchanged with the token endpoint)

• Actions that redirect need to take the above cases into account and either deny access if interaction is required or intensionally allow bypassing, which puts the burden on the application requesting login.