JWT refresh tokens & active_sessions

[renchap]

This is a follow up on #183, trying to find a suitable setup for my use-case.

My app have both a Rails-based web version, and a mobile app that I am working on. For the web, I am using a standard rodauth setup, with active_sessions to allow the used to stay logged on multiple devices.

For the mobile app, I enabled the jwt and jwt_refresh plugins and I am using a pure JWT-based flow for authenticating the requests made by the app. The latest access & refresh tokens are securely stored in the app and refreshed when needed.

Idea 1: only use one of the modules at a time for a session

As the jwt_refresh and active_sessions modules have overlapping features (session persistence & expiration), the easier way to handle my use-case seems to only use one of them at the same time:

• if use_jwt?, then do not use active_sessions and rely on the JWT refresh mecanisms
• else, use active_sessions

This solution would require:

• not calling rodauth.check_active_session for JWT requests
• currently_active_session? should return true for all JWT requests
• add_active_session should do nothing for JWT requests

The biggest drawback is doing so is that you can no longer log out all sessions for a user. Even if you delete the active sessions and remove the JWT Refresh token key, then the user can use the active access JWT token until it expires.

It also creates 2 ways of handling sessions, which adds complexity.

Idea 2: no deadlines for JWT sessions

As discussed in #183, we could set no deadlines for JWT requests in the config, add a session_type field in the active sessions table, and ignore the rows where session_type = 'jwt' when purging inactive sessions.

But the JWT-flagged sessions would never get deleted, which is not really wanted. They would need to be deleted when their token is successfully used for refreshing a JWT session and the new session has been created. On the plus side, JWT sessions can easily be revoked at any time as with normal sessions.

Idea 3: do not rely on active_sessions when renewing the JWT using a refresh token

When there is a refresh token, we could simply look at the JWT access token to see which user this token is for, and authenticate the user for this session if the refresh token is still valid

This has been discussed here and @jeremyevans fears that it might be a security issue, but after thinking about it I think the refresh token is more similar to a remember me cookie, which already works like this if I understand correctly.

If going this way, then revoking the JWT refresh tokens when remove_all_active_sessions is called would void every session & refresh tokens so new sessions will require a new login.

Did I miss something obvious? Do you have any opinions on how to handle this in the best way?

[jeremyevans]

I stand by my original statement: if your active_session expires, you shouldn't be doing a jwt refresh, you should be doing a login. Is there a reason you don't want to relogin on active_session expiration?

If you did want to address this without a new login, maybe there could be some sort of integration (probably separate feature that depends on jwt_refresh and active_sessions) where for JWT sessions, instead of storing the access token as the active session, it stores the refresh token as the active session. Expiring active sessions would remove the refresh token, so while it wouldn't be immediate logout in the JWT case, you couldn't refresh the JWT, so all non-JWT sessions would be logged out immediately, and JWT sessions would be logged out after the access token expiration time. I haven't tried that approach, but it may work.

[renchap]

A web browser is usually far less secure that a mobile app. A mobile app is sandboxed, on a device most often used by 1 person with a robust device lock, and can store the credentials in a secure local storage. So on most mobile applications you are never logged out. I am trying to replicate this, without changing our current settings for web.