0

We have a distributed webapi application that uses OAuth token issued by the provider to communicate with an API, its lasts for a specific amount of time,

We are thinking of storing the token in a datastore and retrieving it before making a call to the api, and have a background windows service refreshing the token for every 1hr or so.

Are there are proven patterns on how to refresh the token in a distributed application ?

Thanks -Nen

nen
  • 621
  • 2
  • 10
  • 26
  • Have you looked at OWIN and creating OAuth tokens and refresh tokens? Here's a good approach to handling refresh tokens: http://bitoftech.net/2014/07/16/enable-oauth-refresh-tokens-angularjs-app-using-asp-net-web-api-2-owin/ – Karen B Jun 05 '15 at 17:37

1 Answers1

0

We are starting to implement something very similar. We are looking at Redis cache to store the tokens. This way any number of distributed applications can get or update the cache as needed. Redis can be scaled out and distributed as well. This removes the need for any syncing service and it's available with a pretty simple interface for communication. If any client reads an expired token, it's in charge of removing it from the cache (circuit breaker) and notifying the auth service. We have an auth service that is in charge of adding to the cache. It can either do a refresh of the dead token, or just ignore the notification if we don't want automatic refreshing. We don't have it fully functional yet, but it's coming along nicely.

ManOVision
  • 1,853
  • 1
  • 12
  • 14
  • Few questions: 1) Assuming the front end is distributed, at any point of time lets say we have 2 or 3 front ends accessing Redis to get the token, assuming all the 3 got the token and its expired, who is going to update it ? all the three ? – nen Jun 08 '15 at 08:55
  • All 3 would get the expired token, all 3 would issue a call to Redis to remove the old token, and all 3 would send a notification for the auth service. We are using Azure Service Bus for messaging. Now the clients have a couple choices. They can show a loader for a set time, say 2-3 seconds and then try the cache again. If the auth service refreshed the token, it would be there. Or, the client could simply clear any state it needs to and redirect the user to the auth service. This is more likely. This is similar to MS and redirecting the user to login.live.com. – ManOVision Jun 08 '15 at 13:54
  • Since this use of Redis is a simple key-value-pair, any request to remove a key that's not there will simply be ignored. With Service Bus, we ignore duplication messages so no worries about the auth service trying to refresh the same token many times. Even if an extra message went through, an extra refresh won't hurt anything. – ManOVision Jun 08 '15 at 13:58
  • I ended up using Redis as well. There might be a better way to do this, but I set a lock on Redis if a token is being refreshed. The issue still remains that a task could be in mid process and a token gets updated. In this case I set a retry with a random time less than 5 seconds. – invertedfjord Aug 31 '21 at 15:49