Question about drf-jwt usage

[sphrak]

Hello,
I intend to use JWT authentication for my API endpoints. However I "think" I have a few concerns with it possibly that might make it not suitable for what I intend, I'd love to hear what you think, if its even suitable for my use case.

Use case

In my android app I want to be able to ask for email & password, 1 time and then indefinatly use a refreshed token, thus not saving email nor password in the app - this, to be able to access the protected endpoints.

Problem

By default it seems DRF-JWT implementation has a refresh window of 7 days - and my question is then could I disable this entirely? I understand that if I do, if a key is ever leaked - it could be used by a malicious user. However, I also thought of using the JWT_GET_USER_SECRET_KEY to mitigate that a little bit so in the case of a leaked key, the user could reset the jwt_user_secret_key and also have JWT_EXPIRATION_DELTA to something like 5 minutes.

Question

So my question is, would this be a "good" approach? or am I misusing the entire concept of the JWT implementation? as you might understand I am new to this so any input would be appreciated.

[Alex3917]

What's a "good approach" really depends on your industry. I run a social site, so the token doesn't expire for 30 days. But if you log out or reset your password, the token is invalidated (using JWT_GET_USER_SECRET_KEY).

But for a client I do some consulting for, the tokens expire after 10 minutes of inactivity. Different industry, different rules.

[sphrak]

Yes of course, that is true. I guess my question boils down to - is it considered a "doable" approach - I mean is there any potential disadvantages for forever being able to refresh a token, under the pretext that each user uses their own secret key and invalidate it on their own will, or per password change or deactivation of user account. Its an interesting topic, and some of the uncertainty I have aswell is that people say one shouldnt use JWT.. due to various reasons, but to me it seems to be good for my purpose.

PS, when you say token expires 10 minutes, that is not the same as saying you can "refresh" for 10 minutes then its impossible to get a new token right? Because I am under the understanding that an infinate refresh window, will allow client to get a new token "forever"? and I can configure each of those issued tokens to have a lifetime of only 5 minutes for example?

Sorry for the wall of text, but I am really interested in this, and thank you for replying - double thank you for your description in here: #385 it cleared some things up for me :-)

[Alex3917]

when you say token expires 10 minutes, that is not the same as saying you can "refresh" for 10 minutes then its impossible to get a new token right?

Correct. Basically the front end will automatically refresh the token if it's been more than a minute or so since it's last been used, but after 10 minutes it can no longer be refreshed. So then it expires in another couple minutes after that.

Because I am under the understanding that an infinate refresh window, will allow client to get a new token "forever"? and I can configure each of those issued tokens to have a lifetime of only 5 minutes for example?

Yes and yes.

The reasons people are against JWTs is mostly because it's not a good standard due to it being easy to implement incorrectly. Which is true, but doesn't really have much of an impact on how your token expiration policy should work... Basically just treat token expiration the same way you would treat a cookie-based session. (JWTs are also vulnerable to XSS instead of CSRF, but not sure this should have much of an impact either.)

So yeah, difficult to really offer any concrete best practices since it really depends on the assets under protection, the kinds of users you have, how easy it is to force a password reset, etc. I think it's generally considered a bad practice to have tokens that last forever, but perhaps up to a year could be fine depending on the kind of site. It's just hard to generalize when the possible situations range from chatting about Pokemon on a message board to withdrawing Bitcoin from an exchange.

[sphrak]

@Alex3917 Okay, thank you for explaining and giving me a better understanding. I do not send super sensetive information, but of course I'd like to offer a good balance between usability and security. I feel quite confident now that I can use it the way I intend to use it.

Again, thank you and I wish you a nice upcoming weekend meanwhile :-)

PS: if I specify the JWT_GET_USER_SECRET_KEY do I still need JWT_SECRET_KEY setting?