Currently doing a refactor to OIDC changes and have a question about the client credentials grant vs refresh tokens.
My use case is as follows:
- Many users running workflows in a server to server manner.
- Users/organizations have varying scopes.
- Highly distributed with many nodes/vms/containers needing to get an access token.
The reason I ask this is non-interactive clients in Auth0 could closely resemble service accounts in Google Cloud. However I don’t want to hack some functionality here.
What are the limitations on creating non-interactive clients vi API? Ratelimits? Max number of clients?
To my knowledge, currently there is no limit on the maximum number of clients. However, the lack of a limit at this time does not imply there will never be one, although if a limit is applied I’m sure is one sufficient for the majority of use cases. If you have an idea on the concrete number you’re looking for then do update your question with that information and some context around the need for the numbers in question as that is always valuable information to have for analysis.
With regards to rate limits, if you haven’t done so already you should check the reference documentation. For actual concrete numbers on the limits you should always check the associated HTTP headers included in the response of endpoints that are subject to rate limits.
Having said of all of that, in general the debate of using a end-user grant with refresh tokens versus going with client credentials is more centered in the actual need of a user identity when the calls are performed. In particular, with a refresh token you’ll get access tokens associated with a specific user and that represent the ability of an application to perform certain operations on the behalf of the user while client credentials issue access tokens that are associated with the client application itself.
Another thing to consider is if you need OAuth2 or if another called authentication mechanism can be used. For example, if a subset of the services are in a controlled environment with no public access and are all controlled by the same entity then you may use other authentication mechanisms that are less complex.