Using AUTH0_INCLUDED_ONLY: To Avoid Affecting APIs

Get Help
,
1

Hi folks.

As stated in previous posts, I am currently creating an ADO pipeline that deploys the config files created by the Auth0 Deploy CLI to each of our environments (staging, dev and prod).

I have deployed the config from Dev to Staging, just because staging is the only environment I can use without anyone’s permission and to populate the largely empty staging tenant with the email templates etc, from Dev. I used this line in the YAML: ’ AUTH0_INCLUDED_ONLY: ‘[“actions”, “branding”, “emailTemplates”, “pages”]’’

My Tech Lead colleague wants me to do E2E testing in each tenant if I deploy this, meaning he wants me to check I can do things like ask Auth0 for tokens for our authorized applications through doing the relevant API call, test token exchange, user creation and so on.

My question is, given my pipeline is just limited to email templates, actions, pages etc…is the E2E testing I described really necessary? Surely my pipeline has no chance of disrupting the E2E user flow right?

Let me know if it does, please.

Thanks as always for your excellent support!

3

Hi @shayan.bhattacharya

You are asking whether E2E testing is necessary when your Deploy CLI pipeline is limited to deploying only emailTemplates, actions, pages, and branding resources, and whether these resources can disrupt the end-to-end user authentication flow.

To understand why the E2E user flow is at risk, let’s break down the assets you are deploying and their relationship to the authentication pipeline:

  1. emailTemplates and branding: These are largely cosmetic or asynchronous. A typo in an email template or a broken logo URL will degrade the user experience, but it generally will not stop a machine-to-machine API call or a token exchange.

  2. pages: If you are using Custom Universal Login pages, you are deploying custom HTML, CSS, and JavaScript. If a syntax error is introduced into the JavaScript on the login page, the form submission could fail, completely blocking the user’s ability to authenticate.

  3. actions: This is the most critical element. Auth0 Actions execute synchronously during the runtime of your identity flows (e.g., Post-Login, Pre-User Registration, Client Credentials Exchange).

    • If an Action has a logical error, an unhandled exception, or a timeout, the entire authentication transaction fails.

    • If a Post-Login Action is meant to append custom claims to a token and it fails to do so, your downstream authorized applications might reject the token, breaking the E2E flow even if Auth0 successfully issued it.

Because your pipeline overwrites these executing scripts in the target tenant, a seemingly innocent code change in Dev could inadvertently break the Staging or Prod environment’s ability to issue tokens.

[OFFICIAL RECCOMENDATION]

The E2E testing is necessary. By testing the core flows (token fetching, user login, token exchange), you are verifying that the newly deployed actions and pages compile and execute correctly within the context of the Staging environment.

When you perform these tests, pay special attention to:

  • The Happy Path: Can a user log in? Can your backend APIs fetch a token?

  • Token Payloads: Decode the tokens (e.g., using a tool like jwt.io) to ensure that any custom claims populated by your actions are present and formatted correctly.

  • Action Logs: Keep the Auth0 Dashboard open to Monitoring > Logs. If an E2E test fails, the logs will immediately tell you if an Action threw an exception or timed out during the transaction.

Kind Regards,
Nik