Help Needed for Strange ClientID/Secret Behavior in Two Applications

Hello. My team uses Auth0 for user logins for our products, but the team members that implemented it are long gone. This is all quite new to me, so please forgive my ignorance.

We have two tenants, Prod and Dev. On each tenant, we have the same two applications, which we’ll call Mario and Luigi. After a recent deployment, we have started getting errors in Luigi: you could still log in as normal, but when the program made certain API calls, the HTTP request would get a 401 Unauthorized error. While exploring, I eventually noticed that the program actually worked 100% fine if we plugged in the ClientID and ClientSecret for Mario rather than the ones from Luigi. Strangely, this issue is happening across both tenants. If we point to Mario prod or dev, it works. The opposite is true for Luigi.

All this makes me feel that the issue might be some Auth0 configuration issue. So, figuring that Luigi was somehow incorrectly configured, I compared the two applications. The only significant differences (not the name/ID/secret etc) that I could find were:

Allowed Callback URLs
Allowed Logout URLs
Use Auth0 instead of the IdP to do Single Sign On
JsonWebToken Signature Algorithm
OIDC Conformant

I copied everything that was different in Mario into Luigi, but nothing changed. I still got the error when I pointed to Luigi. I found nothing different in the addons or connections. Rotating the secret for Luigi didn’t change anything either.

A few other things I looked at: I checked the JWTs generated on the online reader, retrieved HARs from Chrome, and looked at the serialized response class in Visual Studio, but the differences between them didn’t stick out as unusual to me.

So, that brings me to my question: Does anyone have any suggestions as to what else could be different between two applications? As far as I can tell, an Application in Auth0 is just a set of credentials that you give to a program, so I am not sure what else could be wrong.

Thank you very much,

John