Reputation: 8685
Maybe someone could clarify me, as I am not finding that clearly written in documentation...
I do have a single application, which is running on multiple machines. With OAuth2 I do have to obtain an Access Token in order to work with Google API. Do I need to use single Access Token across all my hosts and take care that it would be synchronized across them (which increases the complexity level, as once token expires - it must be refreshed and again distributed across all hosts), or it is possible that each host could get its own token and cache it locally?
I am not really sure either 2nd option is safe (though it would be easier to implement), as documentation writes that token can become invalid once it is refreshed. Could it happen, that while one host is creating its "own" token all other tokens (from other hosts) become automatically invalid?
Upvotes: 6
Views: 7030
Reputation: 932
I assume your application is a web application deployed in a cluster, is that correct?
Is there session state distributed over the cluster? If so, add the access token to the session.
In theory you can have multiple access tokens, but don't rely on that. There are rate limits that you can run into, but if only occasionally a machine is getting multiple access tokens it is not an issue.
Upvotes: 5
Reputation: 4019
Since it is one application, one Access Token is the preferred method. If you have multiple Access Tokens, then you would need to treat each machine as a separate application and the end user would need to authorize each machine separately.
To avoid the cascading refresh (machine one gets expired response and goes to refresh, then machine two does the same thing prior to machine one getting the new Access Token), you will need some sync logic wherever you store the tokens. A simple status flag in the data store(Use existing token, Getting new Token) could help with the sync.
Upvotes: 2