I have successfully got the access_token and the refresh_token from a Web Flow OAuth2. My scope do include full and refresh_token.

The issue I have now is that when I login after with server to server API communication, I can use the refresh_token to get a new access_token when I POST to /services/oauth2/token and I do get a response from Salesforce. The problem is that in the return response there is no refresh_token returned from /services/oauth2/token.

Has anyone run into this issue to get refresh_token from /services/oauth2/token?


1 Answer 1


The refresh token is "permanent", meaning it lasts until it is revoked or manually logged out. You do not need to get a new refresh token every time you get a new access token. You can use the refresh token to get as many new access tokens as you'd like. Note that the system prefers to return an existing, non-expired access as opposed to a new one when you use the same refresh token. In other words, if you do a refresh, and it's the same token, the previous token has been refreshed instead of being issued a new token. As a developer, you don't really need to be concerned about this implementation detail. Just remember that you only need a single refresh token, and you can refresh your access token any time you'd like.

  • Thanks sfdcfox. I always thought that the refresh_token also need to be refreshed too. Many thanks for your help. Commented Nov 15, 2017 at 19:28
  • Then why not just use the refresh token as an access token? All this back-and-forth is just security theater. Commented Mar 31, 2020 at 20:50
  • @StackOverthrow (nice moniker). See answer. Basically, the RT is useless without the CS, so a client can store the RT and present it to the server to get a new AT, but a rogue agent can't use the RT to gain access. OTOH, the AT can be expired early if compromised without affecting the RT. It's not just theater, it has an actual design behind it.
    – sfdcfox
    Commented Mar 31, 2020 at 21:58
  • The caveat in that answer, and the issues raised in the comments, are why I'm calling this theater. With this scheme, the CS becomes the thing you need to protect, as you normally would need to protect the AT. Literally the only difference is all the hoops you need to jump through to obtain a AT using the CS. And the problem is that toolchains for consuming Swagger/OpenAPI metadata don't support jumping through all these hoops; they expect to be provided with a long-lived AT. Commented Mar 31, 2020 at 22:14
  • @StackOverthrow Not all systems use RT, because it doesn't make sense in the context (typically, because the CS can't be guaranteed to be secure). In implementations where RT is viable, it is not theater, any more than the "missile silo two-key launch system" is just theater. The RT/CS design means that, properly implemented, two systems have to be compromised, which is usually harder than just one.
    – sfdcfox
    Commented Mar 31, 2020 at 23:02

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .