I haven’t tried that, but I think I found another solution:
The API uses a dependency injection container that allows me to switch from the token verifier implementation used by the middleware.
The middleware constructor takes a \Auth0\SDK\Helpers\Tokens\TokenVerifier and the DI container is normally configured to inject an asymmetric token verifier (\Auth0\SDK\Helpers\Tokens\AsymmetricVerifier). When testing, I simply override the DI container definition to inject a symmetric token verifier instead (\Auth0\SDK\Helpers\Tokens\SymmetricVerifier).
This allows me to create an entirely customized and valid (or invalid!) token using a hardcoded issuer, audience and secret. As far as I know, there is no way for someone to accidentally enable this behaviour outside of testing (and even if there was I won’t deploy the test suite to production anyway).
Actually, I just realized that the same approach could be used to just replace the JWK in the AssymetricVerifier during tests using a fake key 