About GRRA

There are at least two scenarios I can see where this can break down - 1) error occurs after receiving the updated tokens but before the token is stored in the db, and 2) multiple requests to refresh the tokens in flight simultaneously. In the first case, there wouldn't be a way to establish a new refresh token in a machine to machine scenario since the original refresh token would be invalid and there’s no user to authenticate and generate a new set of tokens. In the other case, the second request to refresh the tokens could update the db storing the refresh token and cause the refresh token obtained by the first request to be invalidated before the first overall request is complete.   I still don’t understand why this flow would be appropriate in machine to machine scenarios where all requests are related to a single account. Why can't the API key and secret be used when exposing the secret via user's browser isn't a concern? I don't think customers should be required to store tokens or any other state just to use the CC API. ... View more

If the refresh tokens don't expire, how should apps handle the following error?   { error_description: 'unknown, invalid, or expired refresh token', error: 'invalid_grant' }   When this happens in an app that's machine to machine that doesn't receive user input, there doesn't seem to be a way to recover and refresh the tokens.   Since the CC API seems to ignore a machine to machine scenario where refresh tokens really don't make a whole lot of sense, especially since using the API key and secret seems reasonable when a user's browser isn't involved, I'm hoping someone can provide information on how to recover from an error when a refresh token becomes invalid. Otherwise, please confirm that the CC API cannot be (reliably) used in a machine to machine scenario. ... View 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 [1].   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?   [1]: https://auth0.com/blog/using-m2m-authorization/ ... View more

Each post like this seems to end the same way, with support pointing folks to the server flow docs page. Unfortunately, I've read it several times and still don't see how a refresh token solves the problem of server to server authentication without requiring user input. As I understand the process of refreshing the token as part of the server flow, you'd POST to the CC auth endpoint with the refresh token so you can obtain new access and refresh tokens. The problem is that in a server to server scenario the server would need to maintain the last refresh token that was obtained. That's not very realistic, partly because you could have multiple requests to an API trying to make this same auth request, and also ruins the ability to remain stateless.   I hope I'm missing something, because it would be a shame if CC isn't providing a method of server to server authentication via the new v3 API. It just seems like both auth methods assume a user is making the request instead of the scenario where another API is making the request. If the latter is not possible, I hope a support rep will confirm that and have it included in the documentation to prevent confusion. ... View more

I've read through the server flow docs several times and still don't see how you can you can use the refresh token to obtain new access and refresh tokens more than one time. As I understand it, once you use the refresh token to obtain a new one it becomes expired and can no longer be used. That seems to suggest the refresh token needs to be stored on the server so it can be used on the next request. If this is truly the recommended approach, it doesn't sound feasible if you have multiple users making the same request simultaneously. My preference is to keep things stateless and not store the tokens.   It seems awfully shortsighted if this is the only way developers can authenticate server to server. Please let me know if there's something I may be missing related to refreshing the token. ... View more