When creating a Marketing Cloud Application (to be listed on the HubExchange) an installation of the App issues a JWT token that is received by the defined login end-point. The token contains, amongst other things, an oauthtoken and a refreshToken variables.
I understand that once the oauthotken expires, then the "server" issuing the requests needs to call the refreshToken API call to request a new oauth token, via the refreshToken. The call then returns both a new oauthtoken (to be used, until it will also expire) and a new refreshToken (to be used when the "new" oauth token expires).
Assuming the above is correct, my questions are as follows:
1) Does the refreshToken have any expiry of itself? Assuming we are developing an offline application that performs an operation via the API once a week, would we be able to use the refreshToken to request an oauth token within one week (or 1 day) after the JWT token had been received? (or after a refreshToken had been called?)
2) Does the ability to "refreshToken" (given the user's refreshToken) depend on the user still being logged in to the system?
3) The requirement to "replace" the refreshToken for every call to the refreshToken API call makes it such that the process of "retaining" the connection (or retaining the authorization to access the users' account via the API) much more error prone. For example, if the application that uses the refreshToken has a bug and is not able to properly store the refreshToken (after it had been replaced), then it will not be able re-acquire access to the user's data without asking the client to re-install(?) or re-login(?) to the application such that this will in turn issue a new JWT token with a new set of oauthtoken and refreshTokens... Am I missing something here? is this intentional? is there a work-around? (obviously this issue could be problematic in other cases, not just when there's a bug in the application invoking the API calls).
Thanks, VC.
