The Community is hosting an End of Summer sweepstakes! Participants must complete tasks to earn tickets that will enter them with a chance to win a free year of Constant Contact and other great prizes!*
*No Purchase Necessary. For Official Rules, visit here. Constant Contact’s End of Summer 2020 Sweepstakes ends on October, 20, 2020 at 11:50 PM EST.
I'm still unclear why you would involve a refresh token in a machine to machine scenario. I already have the client id and secret - neither of which are public because this is running on a server and not in a user's browser. Why can't my application make a request to exchange those for an access token that expires after a period of time? Your system could then verify that access token before processing requests. An example of this can be seen on Auth0's site . Unfortunately, your refresh token process is very inefficient for machine to machine scenarios like this and requires APIs to make several unnecessary requests. If I'm not mistaken, my API will need to request the current access and refresh tokens from my db, then make a request to the CC API only to find out the access token has expired. Now I have to make another request to your API using the refresh token to get another access token and refresh token, then save those tokens to my db again. Finally, I'm ready to make another request to the CC API with the new access token. While this is happening, I have to hope another user doesn't make the same request, since their request would fail as well and would cause them to do this same dance. Problem is it would be unnecessary since another user just fetched a new access token - but I really don't want to block requests while one user is getting a new token. Did your team consider the approach of exchanging the client id and secret for an access token like Auth0 uses in machine to machine scenarios? : https://auth0.com/blog/using-m2m-authorization/
... View more