I would like to know the best practice to authenticate m2m applications to my API. Currently I was using client access grant, but soon I ran to 80% of my quota.
My application is a serverless function, so caching the obtained token is not really possible without adding a memory cache to my infrastructure, so I was thinking about refresh tokens if they might help me out? I am thinking about having a refresh token with a validity of 30 days, but asking myself if generated access tokens will be counted in the quota or not?
Unfortunately, refresh tokens are not supported in M2M applications. Refresh tokens are not issued to M2M clients because the OAuth2 client credentials specs advise against it:
If the access token request is valid and authorized, the authorization server issues an access token as described in Section 5.1. A refresh token SHOULD NOT be included.
The best option for M2M apps would be to add the caching for the Access Token to reduce the number of exchanges.
many many thanks for your prompt response, this helps me a lot and most probably saves me a lot of time of trial and error, as I would have most probably started to get a refresh token in my m2m app.
Do you know any articles or documentation about Auth0 and serverless applications?
It will be a real m2m scenario using a python cloud function that initiates the authentication process without user interaction.
After searching for a while now I believe what you described earlier to cache the received token is my best option.
Took sime time right now to read the different parts of the RFC @stephanie.chamblee mentioned earlier. This is absolutely not about m2m authentication. The quote you copied is about requesting an access token and this response should not include a refresh token. You must explicitly ask for a refresh token.
Thanks for sharing this! There are times that you’d make a request to the /token endpoint specifically for retrieving a Refresh Token, but only if the client was originally issued a Refresh Token. In other words, a request specifically for a Refresh Token is only made when the client needs to retrieve a new Refresh Token.
Normally the Refresh Token would initially be issued at the same time as the Access Token. For example, when using the Authorization Code flow, you’d request the offline_access scope in the /authorize request. Auth0 would return an ID Token, an Access Token, and a Refresh Token when you make the /token request.
When using client credentials flow (aka M2M), Auth0 will not observe the offline_access scope, and a Refresh Token will not be issued.
Auth0 supports Refresh Tokens for the following authorization flows: