0

I have created application starting with JHipster and at that point implemented Token-based authentication provided by JHipster. Even though I implemented Server Side Controller as RESTful services - I had to keep User Context on server in Custom Implementation of UserDetails because of complexity of my multistage transactions. It all works well in single JVM instance environment but when want to implement it as a horisontal cluster I need to make sure that requests from the same user keep redirecting to the JVM where it's context is. I use Tomcat with Apache HTTP for cluster load balancing and implementation. Can mechanism similar to sticky sessions be implemented in cluster with this type of authentication (or OAuth2 - also stateless)? Replicating User Context via distributed cache is not an option for me as it can be quite heavy.

ivan
  • 151
  • 1
  • 1
  • 4

1 Answers1

0

If I understood question, the answer is - yes, OAuth2 is stateless. Simplified image looks like this:

  • User become authenticated on the server (login)
  • User authorize a client to access resources on the server
  • Spring generate access_token and put mapping between access_token and the user details to a token store.
  • Client try to get the resource with access_token
  • Spring intercept the request -> extract the token -> get user from the token store by the token -> add the user to the context.

By default spring uses in memory token store, but you can setup JDBC one out of the box or just implement yours.

Sergey Yamshchikov
  • 979
  • 7
  • 11
  • Sorry if question is not clear - my bad. The question is actually - how to implement something like sticky sessions in cluster when using OAuth2? – ivan Mar 06 '15 at 10:51
  • @ivan I suppose all you need is shared token store. All your nodes will be able to identify the user. – Sergey Yamshchikov Mar 06 '15 at 11:08
  • Sorry I'm not confident in sticky session, but you can use info from the shared token store to manage your load balancer. – Sergey Yamshchikov Mar 06 '15 at 12:24
  • But I don't really want user to jump into other JVMs/App Server because it's context need to exist only in it's initial JVM. It's context will be fairly heavy memory vise as there will be cached business related objects in it and I don't want to share it across cluster via distributed cache because of performance issues in that case and benefit of clustering is unused then - it would just end up with heavy heap usage in each JVM for all users then. – ivan Mar 06 '15 at 13:43
  • @ivan I suppose you use cookies based strategy with apache http load balancer. In that case it should work out of the box if your client is a browser. The load balancer will put a cookie to the browser, and the browser will send the cookies with each request (it's standard browsers behavior). If your client is native or something non-browser based you have to manage work with the cookies by yourself. – Sergey Yamshchikov Mar 07 '15 at 23:38