I've implemented the client credential flow for accessing my API within my automated testing setup. The client ID and client secret are stored as secrets, and everything works smoothly. However, there's a limitation with Auth0's token generation through the client credential flow, capped at 1,000 tokens per month. Going beyond this threshold results in additional charges to my account. To work around this limitation, I'm thinking of transitioning to the resource owner password flow, which doesn't have a token restriction. I'll simply store the username and password as environment secrets, and use those to generate access tokens for my API. Is there a disadvantage to this, from a security standpoint?
For a machine to machine flow, the security should be the same, since in each case the client provides the same security properties, eg:
Yet it is a little unsatisfactory to use the resource owner password grant:
test clientOAUTH API TESTING
Sometimes a better option is to mock difficult OAuth infrastructure. For example, if you want to test calling an OAuth secured API as a particular user, you will want to avoid a full authorization code flow, possibly with multi-factor authentication.
One way to mock the infrastructure is to use a JWT library to issue your own tokens. These must use identical JWT access tokens to those received by APIs, except for a different digital signature. You can then point your API (in particular environments) to an alternative JWKS URI. This should require zero code changes to APIs. It can also be quite educational for developers and testers, to help them to understand the correct security.
For some examples, see these resources of mine:
Of course, this would fit somewhere in a wider test strategy that also includes some real end-to-end flows using real Auth0 tokens. The end-to-end tests give you full confidence that the overall system is working. When focusing on detailed API testing, the mocking technique may give you some other options.