I am designing web load tests and I first used the grant type ‘client_credentials’ but later noticed this does not mimic real user scenario’s enough and more important: my pipeline rules weren’t executed.
So, I created some users and realized I then need to do some ‘user-password’ stuff. Luckily, I found I can enable this in the dashboard for my machine 2 machine application.
But I read documentation this is not from a security viewpoint a good practice, enabling the grant-type ‘Password’. Is this correct because I cannot find another way of doing web load tests with my test users, with have different roles etc?
By the way, in examples I read the grant type should be ‘password’, but for me only the following worked:
If you are representing users then you aren’t using a Machine to Machine flow. M2M in the context of Auth0 is a different way of saying Client Credentials, more or less.
If you need to get user access tokens for testing, you are still representing a user, albeit test users. As for the risks; yes, there are risks associated with the Resource Owner Password Grant (ROPG).
In order to use the ROPG:
Your application must handle user passwords. This leaves the possibility of mishandling plaintext passwords (logging, improper storage, etc.).
You are opening an endpoint to accept username/password pairs directly. This broadens the attack surface of your implementation.
These are just a couple of examples of how this flow presents additional risk to your application. There may be other risks I have not touched on.
Realm support is an extension grant that allows different directories and specifications of those directories. You can find an example here.
Again, thanks for clarifying things for me! The terminology used is sometimes confusing. M2M is somewhat equivalent to Client Credentials, helps understand things a bit more.
Concerning the risks, maybe I will resort to Client-Credentials or if this is not an option, protect the endpoint with IP restrictions.