2

I use OAuth 2 for authorization and need to implement it in a load balanced cluster. I've considered a few approaches, but it seems there is no way around a centralized approach. Here are my thoughts:

1. Balancing using source IP

Caching the tokens on one server and balancing by IP would be ideal, however, the IP can not assumed to be static. So when the same user tries to access services that require authorization from another IP with a valid token, it will fail, because it is not cached on this machine. Also other devices logged in with this user will not reach the same machine.

2. Balancing using a load balancing cookie

Also not really an option, since it cannot be assumed that every client implements cookie storage.

3. Balancing using the Authorization header

Balancing by hashing the Authorization: Bearer token header is problematic, because the first request (for requesting the authorization token) has no Authorization header, thus, the following request might not hit the same instance.

My current approach is to use a central Redis instance for authorization token storage. Is there an option left, where a centralized approach can be avoided?

1 Answers1

2

I think you still have two options to consider.

One is to balance by session ID. Application servers usually can be configured to manage sessions either by cookie or a GET parameter added to every link, so it does not definitely needs cookie storage. Additionally, there are very few HTTP clients left that still do not implement cookie storage, so you may want to reconsider item 2 of your list.

The other one is using self-contained tokens, e.g. JSON Web Tokens (JWT) with signatures (JWS). Validation of self-contained tokens may not need central database, each server instance can check token signatures alone and extract authorization details from the token itself. However, if you need support for revoking tokens, you may still need a central database to store at least a blacklist of revoked tokens.

Though I cannot provide you a full-fledged solution, hope this gives you some ideas.

Zólyomi István
  • 2,401
  • 17
  • 28
  • Yes, I've considered those. Unfortunately the centralized nature of token revocation is also a problem here. I think I'll just leave it the way it is. –  Jul 19 '13 at 16:08