Action Module implementation details

Dev to Dev Hub
,
4

Hi @amay

I am sorry for the delayed response to your question!

You are asking whether Auth0 Action Modules run as separate compute that can hold a token in a module-level global variable to improve M2M token caching, whether objects passed into an Action behave as references or copies, and whether concurrency is a concern.

Summary: The documented Action cache is the supported caching mechanism, its hit rate depends on how Auth0 routes each execution, and module-level variables are not a documented caching method, so do not rely on them for token caching.

Root Cause: Your low cache hit rate and high M2M usage have two likely sources. First, api.cache entries are not guaranteed to be available on the next login or credentials exchange, so many executions fetch a new token. Second, an Action that requests a client credentials token can re-trigger the credentials exchange Action, which issues additional M2M tokens. Auth0 Community responses also confirm that the token the Action caches is a separate token from the one issued to the calling application, so caching the Action's token does not reduce the number of tokens issued to your M2M client.

Solution: Stop caching M2M tokens inside the Action, and reduce how often the Action needs a token at all.

  1. Verify whether your Action requests a client credentials token on each execution. Check the Action logs for repeated token requests in a single flow, and check whether the credentials exchange Action runs during its own token request. If it does, the Action is generating tokens for itself.
  2. Remove token acquisition from onExecuteCredentials-Exchange if the Action is only fetching claim data. Move that data fetch to a path that does not call the credentials exchange trigger, or to the service that issues the token.
  3. Cache the claim data rather than the token. If the additional claims rarely change, store the claim results in your own backend service or a shared store such as Redis, keyed by user ID, with a time-to-live that matches how quickly the data changes. A cache hit then avoids both the token request and the API call.
  4. Reuse the token in your own service. If the Action must call your API, have your API accept a long-lived token from a secure store that your service manages, and refresh it before expiry. Do not rely on the Action cache to persist between executions.
  5. Measure the change in M2M usage in the tenant logs and the Dashboard quota view after each change, so you can confirm the effect in production.
  6. Do not store tokens in module-level global variables. The documentation does not describe module-level state as a supported caching mechanism, and Action execution does not guarantee that the same instance serves successive requests. A cache held in memory may be empty on most requests, and concurrent executions do not share it. Because Auth0 does not document this behavior, treat any performance result from this approach as unverified.
  7. Ask Auth0 Support to confirm the execution model for Action Modules, including whether module state persists between executions and whether concurrent executions can share it, before you refactor the token acquisition.

Some helpful links regarding the matter:

Kind Regards,
Nik