Hi @nbarbas - welcome to the Auth0 Community!
First of all, I would like to thank you for being very thorough in explaining what you are doing and what you are trying to achieve. This helps us a lot to provide you with an answer relevant to you. Now, to the technical details!
To explain what’s happening and what you are seeing, I think it’s good to explain what you are executing.
When you use the /oauth/token endpoint with grant_type=password, you are executing a Resource-Owner Password Grant, which is meant to be used in secure environments (like these!) to obtain a token. This is allowed because the contact is made directly from a secure environment (your server) to Auth0, so we both trust the delivery method. ROPG is only available when the Authorization Server (in this case, Auth0) knows the user credentials and can validate them. You can read more about the ROPG here: Resource Owner Password Flow.
For ADFS, the password is not stored directly in Auth0. Instead, we do what’s known as a federation, which allows us to call ADFS and ask them to verify the user’s identity. ADFS then authenticates the user and sends a response back to Auth0, saying, “yes, they are User A, and these are their properties,” or “no, ignore this, error, error!”. At no given point in time, Auth0 handles the ADFS’ users’ credentials - the user logs into ADFS directly, and we obtain a response.
Here is the problem when testing out this scenario. There is no non-interactive way to achieve this flow unless ADFS is set to provide you with a default response. We do allow going directly into the Identity provider by using a connection parameter in your authorize request (see more here), but the Identity Provide would require having an interactive session unless you want to mock those as well.
With all of this information, I am wondering if you would like to explore other scenarios on how you could handle this apart from the original test.
Let me know if you have any further questions - hope this helped.