TouchRequiredSession generates new refresh token when access token is expired

[jonnycatlett]

I am using touchRequiredSession with refresh tokens and custom headers. I am noticing that the refresh-token is rotated when the access token is expired and the refresh token is not. It is my understanding that using touch should not result in a new refresh token, only a new access token. I verified that the refresh token was being rotated with an extended expiry in the data store.

I could be wrong, but it seems like requiredSession(), which is called by touch, always does the rotation when expired. https://github.com/softwaremill/akka-http-session/blob/master/core/src/main/scala/com/softwaremill/session/SessionDirectives.scala#L81

[adamw]

"I am noticing that the refresh-token is rotated when the access token is expired and the refresh token is not. " I'm not sure I understand :) Which tokens are changed and which should stay the same?

[adamw]

If the session is expired, then to prolong the session, it has to be first re-created using the refresh token - which "consumes" it. Hence a new one is created.

I suppose the question is, should touchRequiredSession use the refresh token to re-create an expired session, or fail if the session is expired, regardless of the refresh token being present.

[jonnycatlett]

Hi @adamw. I am trying to setup my application such that I have a short lived access-token (15min) and a longer lived refresh-token (12hrs). I want the entire session to after 12hrs from initial login, but allow the access-token to be refreshed as needed within that time window.

I might be misunderstanding the documentation, but it sounds like touchRequiredSession is the way to handle that. I hoped that the access-token to be rotated as needed, while the refresh-token remained the same. Resulting in the refresh-token expiring in 12hrs from time of initial creation.

What I am noticing is that the refresh-token is being rotated each time the access-token, and when this happens the expiry is also extended another 12hrs. The result will be that the session will not expire until there is 12hrs of inactivity. Currently I don't see a difference in behavior between using touchRequiredSession and requiredSession. Thanks for your help.

[adamw]

Well, unfortunately when the session is expired and re-created, both tokens are currently re-created.

The difference between touchRequiredSession and requiredSession is that if the session didn't time out, touch will extend it for the maximum duration (in your case, 15 minutes), while the normal variant will cause it to time out after 15 minutes since setting it using setSession.

For your use-case, possible solutions are:

• embed an additional timeout when storing long-lived session data and check if after re-creating (this could be embedded into your custom "read session" directive
• implement your own long lived refresh token implementation
• add a configuration switch to akka-http-session and make a PR

Of course, the third one would be best :)

[jonnycatlett]

@adamw Thanks so much for the clarification. I completely misunderstood touchRequiredSession. A new config option definitely sounds like the best approach. I will try to get a PR up for this soon. Thanks again.