Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Search instead for
Did you mean:
Constant Contact wants to help you succeed! We’re celebrating our professional service programs on the Constant Contact Community this month and you have a chance to try one of the services for free! Learn more.
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