feature request : allow unlimited token expiry and customisation of jwt generation to use warden-jwt_auth as authentication backend for native mobile applications

[3pns]

warden-jwt_auth with devise-jwt are greats gems and I would love using them, however it seems to me the usage is opinionated in a way that limits the usage cases that overcomes the initial purpose of this gem to provide JWT token authentication with warden and then devise out of the box integration with devise-jwt gem.

Critical applications such as a banking app force the user to relogin after few minutes of inactivity. On the other hand online mobile apps such as games to be attractive must provide a mechanism to automatically create user accounts without any credential provided, at the minimum for new accounts until user bother to register/confirm an account. For such purposes JWT without expiry are a good solution.

JWT are not cookies and can be long lived without any expiration dates, this spec is supported by the ruby-jwt gem. In this regards devise-jwt implemented system of WhiteListing token is a perfect fit to use it with jwt without expiry, as it is possible to technically revoke them when needed such as when a user loose his device. Unfortunately warden-jwt_auth as stated in the README, makes an expiration date mandatory.

In this case the jwt without expiry is only used for login, then a more standard short live jwt can be used for communication with token refresh at every request, same as Oauth access token and refresh token.

Using Oauth as an authentication provider such as Doorkeeper seems to me not worth it as the risk of the user having his Oauth2/Doorkeeper access token stolen once another mobile app have root access to your app data is the same as if you use a jwt without expiry for the initial authentication and short live jwt as a replacement of refresh tokens. Also a Oauth provider such as Doorkeeper have many features that are not needed by most applications such as providing login functionalities to your users to third party apps.

In this case of JWT without expiry it also makes sense to use more secured encryption algorithm than HS256 that is fine for a short lived session replacement, but can become problematic in the case stated before as HS256 is brute-forceable and use symmetric encryption as opposed to rsa algorithms that use asymmetric encryption and stronger algorithms that are not yet easily bruteforceable. I am no security expert, but this is my humble understanding of the problem.

As a summary the problem for me is the lack of possibility to choose other encryption schemes provided by ruby-jwt and the prevention from generating JWT without expiry. The solution I'm thinking about is to keep the secure by default principle, but let solutions for the users to personalize different step of the process such as choosing the jwt algorithm.

What is your opinion about my use case for native mobile applications, do you think it can be easily implemented with warden-hwt_auth and devise-jwt at moment ? Or do you think it would requires extra functionalities and thus a pull request to the project ? Would you welcome such changes ?

Thank you by advance for your insight and for your great gems.

[waiting-for-dev]

Hi @3pns ,

thanks for your detailed explanation of your needs and your proposals.

However, I think that your changes would suppose reinventing the wheel. You are pushing for changes to transform warden-jwt_auth into something as close as possible to OAuth. But then, why not use OAuth? If Doorkeeper doesn't fits your needs, there are other implementations in ruby or cloud providers. I think that the only reason these requirements keep coming from time to time is because it would be a very easy way to integrate with the super-easy devise. But authentication is not an easy subject, and users must be very aware of what they are doing. Just making expiration time optional and making configurable the algorithm would not be enough for making this an acceptable alternative to OAuth, so I don't want to suggest from here that it is. This library scope is limited and I prefer it to stay as it is. Sorry if it supposes an inconvenient in the speed of development.

Anyway, I'm open to have implemented here is the single feature of having encoding algorithm configurable, but it would not be enough for your needs.

[3pns]

@waiting-for-dev Thank you for your message, After thinking about it, I will roll my own refresh token solution with JWT, and I will see if I can use warden-jwt_auth or devise-jwt for the access tokens part. I can only agree that authentication is not an easy subject. I misunderstood that you want this gem to be a universal adapter in between the JWT logic and warden. I understand now you want it to be a working out of the box solution to protect routes with JWT and warden, my use case is out of the scope of this gem then.

If I end up using devise-jwt for the access token part and I need to make the encoding algorithm configurable I will let you know.

[waiting-for-dev]

Feel free to ask for guidance from this end if needed.