How to correctly combine active sessions and remember?

[janko]

In the official Rails demo app, I have the following in my Rodauth app:

route do |r|
  rodauth.load_memory
  rodauth.check_active_session

  r.rodauth
end

I just realized, if my active session expires or gets deleted, I will automatically get logged back in from the remember cookie. Would it make sense if Rodauth automatically removed the remember cookie in that case (but not necessarily the token in the database)? I believe this can currently be achieved as follows:

no_longer_active_session do
  forget_login
  super()
end

Somewhat related, it would be convenient if we could have a single method to logout the user and remove their remember cookie. I got a report recently that after_change_password { logout } didn't automatically work, because it turned out forget_login also needed to be called.

[jeremyevans]

The purpose of the remember token is to allow you to be logged in after your session cookie expires, and to me, that would include when the active session information expires as well. If you are forgetting login when the active session expires, I don't see the point of using the remember feature. If this is a case where you are purposely deleting active session data, you should also be deleting the remember token at the same time, IMO.

The remember function already hooks into after_logout. I suppose we could add a method to the logout feature that does before_logout, logout, and after_logout, and update the feature to use it.

[janko]

Interesting, for me session cookie expiration and active session expiration are two distinct events that should be treated differently.

When the active session expires or gets deleted, that to me means the user should be logged out, even if they're remembered in the browser, and they should be required to login. Without this behavior, it wouldn't be possible to remotely deactivate a login session from a device where login is remembered.

The remember behavior is still useful here, because that allows the login session to persist after the browser is closed (as then the reference to the active session is lost). Deleting the remember token would invalidate remember cookies from other devices that have active sessions, so those would get logged out as soon as their session cookie expires.

From my perspective, if check_active_session is called before load_memory in the route block, and forget_login is called on no_longer_active_session, I think that would make remember work together with active sessions (unless I'm missing an edge case). I was wondering if active_sessions/remember feature could somehow handle this automatically for streamlined DX, though I don't see a straightforward way at the moment.

[jeremyevans]

Thank you for sharing your perspective.

There is somewhat of a disconnect between the active_sessions and remember feature. active_sessions is explicitly for closing a session before browser close, while remember is explicitly for persisting a session beyond browser close. I can see your point that remember could still make sense when using active_sessions.

However, consider these two cases:

Case 1:

1. User logins in and gets remember cookie and active session
2. User closes browser before active_sessions expiration
3. User reopens browser and is automatically logged in by remember cookie, and gets new active session
4. Repeat from 2

Case 2:

1. User logins in and gets remember cookie and active session
2. User does not close browser before active_sessions expiration, so session is expired
3. User is automatically logged in by remember cookie
4. Repeat from 2

These two cases seem to me to be quite similar. With your approach, Case 1 remains the same, but Case 2 changes, forcing a new login after active_sessions expiration. Any user who is knowledgeable about how things work can trivially work around the change you are suggesting by dropping the session cookie before the active session expires, and relying on the remember cookie to get logged back in.

Similarly, an attacker can reuse the remember cookie after the session cookie is deleted, and it will still allow login. If you are using both features together, you should be deleting the remember token when deleting the active sessions tokens. active_sessions already does that on logout if you choose the global logout option.

To implement what you want, the simplest way would likely be adding before :no_longer_active_session to the active_sessions feature, have check_active_session call before_no_longer_active_session, and have the remember feature override before_no_longer_active_session to also forget_login. However, I'm not convinced that we should treat Case 1 and Case 2 above differently. I'm open to further discussion on it. Maybe I'm missing something.

[thedumbtechguy]

I checked the documentation to see what I would expect in this situation.

Wrt to "expiration", the docs say:

this also by default supports session inactivity deadlines (based on time since last use) and session lifetime deadlines

To me, this would mean, when the member is inactive, their session is removed.
However, since they have a remember me set, when they return, then it is fine to log them in automatically.
This behaviour makes sense to me, and would be what I expect.

---

Where @janko has a strong case, is global logout.
If I decide to log out globally, then I want to invalidate any remember me tokens.
In this regard, I don't think the library is meeting what would be the expected default behaviour.

[jeremyevans]

Where @janko has a strong case, is global logout.
If I decide to log out globally, then I want to invalidate any remember me tokens.
In this regard, I don't think the library is meeting what would be the expected default behaviour.

As I explained, global logout in the active sessions feature already removes the remember token in addition to all active session tokens.

[janko]

Thanks, totally understand your explanation when comparing these two cases. If deleting an active session only clears the remember cookie on the no_longer_active_session path, then an attacker could trivially bypass that by deleting the session cookie often and let themselves always get logged in from remember cookie (thus creating a new session). I missed that active_sessions deletes the remember token on global logout, that's pretty nice 👍🏻

In order for an active session to persist beyond browser close, I think the only way is for the rack session cookie to have a remember-like expiration (example from a recent comment), and not use the remember feature in this case.