If you only had listed the first two points then the recommendation would be for you to create a thrid-party application in your tenant to represent your customer application (First-Party and Third-Party Applications). The application could then use any of the OAuth 2.0 flows to obtain an access token that would allow it to call your API.
However, the above implies that the end-users authenticating into that third-party application will need to exist in your tenant.
Can you clarify how literal is the third point you mentioned; in particular, when you say:
don’t want to create…
does this mean that you just not want to have to create these users because you don’t really manage their credentials and as such this is a dynamic set of users that is controlled by your customer?
If yes, then this would be solved by your customer providing their own identity provider for this set of users and you would just create a connection in your Auth0 tenant; this way any user from the upstream identity provider (your customer) could login without you having to first create any user profile record in Auth0.
However, the above would still lead to user profiles being created in your Auth0 tenant; so if your third point is about not having any notion of those end-users in your own Auth0 tenant then I don’t see how this could be made to work.