Refresh token becames Invalid

Hi Vladimir,

This Session duration on Sugar 7 blog post that I wrote a while back should give you a full picture on how it all fits together and most of the client/server side possible causes.

Hope it helps

Vladimir, did you get an answer to this?
My experience is that :
-you login to get a set of tokens
-the access token expires after an hour
-you use the refresh_token to get a new access_token, and it sends back a new refresh_token as well
-as of this point the original refresh_token is invalid

This means that if I have several microservices deployed (or even the same one scaled to 4 instances) the first one of them to refresh the token can continue, and the others fail thereafter.

This question has been asked here a number of times and never answered to the best of my knowledge
wcn

Hi Wendell,

I'd recommend that each of these microservices use a unique platform ID which would allow each of them to have their own access tokens and refresh tokens.

How platform parameter works in Sugar v10 REST API « Sugar Developer Blog – SugarCRM 

Obviously, I understand that with scaling you could have any number of microservice instances connecting to Sugar which could make registering platforms problematic. Is it possible that you could deploy a gateway service that manages communication with Sugar from a single point?

These integrations are deployed in an elastic way in the cloud.  I find that when more instances are spun up due to load they rapidly start a token war with existing instances because the refresh token's between instances become different, and only one is valid at a time.  This destroys the scalability of the app.
There is no way to allocate separate platform ID's to each instance because I don't know how many there are.  Each instance is only aware of "itself" and would/should not dynamically adjust its platform ID.
I just can't imagine how I could create a dynamically scaling microservices implementation which access SCRM Rest interfaces given the OAUTH mechanism it employs.
I have recommended that we stop development of this integration.

wcn

These integrations are deployed in an elastic way in the cloud.  I find that when more instances are spun up due to load they rapidly start a token war with existing instances because the refresh token's between instances become different, and only one is valid at a time.  This destroys the scalability of the app.
There is no way to allocate separate platform ID's to each instance because I don't know how many there are.  Each instance is only aware of "itself" and would/should not dynamically adjust its platform ID.
I just can't imagine how I could create a dynamically scaling microservices implementation which access SCRM Rest interfaces given the OAUTH mechanism it employs.
I have recommended that we stop development of this integration.

wcn

You shouldn't be trying to share refresh tokens between Sugar instances. There would be a refresh token for each instance + user. You don't need to keep generating Platform IDs, that's not what I was suggesting. You can't have multiple clients connecting to same Sugar instance using same platform id at same time or you'll run into session conflicts. There are ways to mitigate.

If you'd like please reach out to the SugarCRM ISV team, we can setup some time to talk through what you are trying to accomplish.

Lets be clear, I have only one Sugar instance in play here.  It is an "on demand" instance provided by SCRM.  Let me summarize my problem a little more clearly:

The requirement:

The design time tool must be able to log on to scrm, and obtain a set of tokens for use in the design session and ultimately for the deployed app.  It therefore caches a set of tokens for its own use and for applications it creates.

The design time can deploy one or more applications into separate containers in the runtime.  Each of these apps will have the set of tokens acquired during design embedded in them.

Each instance of each application can be scaled from 0 to N times.  Each scaled instance carries along its tokens and application logic.

So the design time has a set of tokens it uses for fetching schemas etc while building apps.  Each instance of each deployed application has a copy of those tokens.

The problem:

As soon as the original token expires the refresh token is used to get a new token, and at that point all other instances are using invalid tokens and fail.

The documentation suggests that OAUTH keys can be allocated on a "per application" basis and that multiple things, like cell phones, can use them.  I just don't see how.

Your thoughts will be appreciated.

wcn

P.s.  This exact paradigm is what we use with Salesforce and Marketo with reasonable success.  No session conflicts etc.