Jwt-auth: Questions about refresh and refresh ttl

[boriswexler]

Hi - I am somewhat new to this topic, so sorry if my questions are naive.
I am developing a mobile app where the desired behavior is for the user to login once and stay logged in afterwards. My questions:

• as I understand the wiki, the refresh ttl is mandatory and means that there will be a certain period of time after which tokens will not be refreshable without the user logging in again. Is that correct and if so is there a way to get around it?
• am I correct in assuming that if the user doesn't use the app during the tll time I will still be able to refresh the token without the user logging in provided we have not exceeded the refresh ttl? So if my ttl is 60 mns and my refresh ttl is 2 weeks, as long as the user uses the app within 2 weeks the app will be able to refresh the token even if it has been more than 60mns?
• I am using laravel 4 and won't be able to migrate to 5 before we launch, which means I don't have access to the provided middlewares. In order to refresh a token that has expired its ttl is it preferable to have the front end application hit an endpoint to refresh it first, or to have the backend app automatically refresh it (which I believe is what the middleware accomplishes) when a request is made with an expired token?

Thank you in advance for your help.

[jossemarGT]

Hey! Just wanted to help and these are my suggestions:

• For this question, read the other two answers.
• I haven't tried with long ttl's, but, by definition if you make a request to refresh your token the only thing that you need is the old one and the issuer (your backend) will send you a new one, this workflow doesn't require the user's credentials.
• As said before, the client needs to explicitly ask for a new token, you can set a refresh_ttl bigger than the ttl and when you get a 401 response (the token has expired) your client application has to ask for a new token with the old one.

Hope that helps. :octocat:

[boriswexler]

Thanks a lot, very helpful.
Just to be clear - am I correct in rephrasing what you are saying as follows: if the ttl has expired and the client makes a request passing the expired token, the backend will automatically generate a new one and send over with the request without having to manually request a new one. If the refresh ttl has expired however the client will receive a 401 but will be able to then make a request for a fresh token without requiring user credentials, just passing the expired token? In other words there is no need for submitting user credentials again at any point unless it is client driven specific behavior?
Thanks again.

[jossemarGT]

Yes, if you have a token (even expired) and its living time (ttl) is lesser than ttl_refresh your client still can ask for a new one, just with the expired one and without the user's credentials. The module (jwt-auth) itself won't auto refresh your token, the client application has to know what to do if receives a 401 response and still have an old token.

[boriswexler]

I see, thanks again.
So what is the practical application of ttl_refresh? As per what you are saying it only has a practical impact if its value is less than the ttl? (in which case the user will have to reauthenticate when tokens expire?). I think what's confusing me is the mention in the wiki: "Refresh time to live - refresh_ttl - This is the length of time, in minutes, that you can refresh a token within. For example, if you set this to 2 weeks, then you will only be able to refresh the same chain of tokens for a maximum of 2 weeks before the token will be 'un-refreshable' and the result will always be a TokenExpiredException. So after this time has passed, a brand new token must be generated, and usually that means the user has to login again."

I need a setup where the user never needs to login again (similar to what most mobile apps other than banking/financial do).

[boriswexler]

Following up on this I found the following post http://stackoverflow.com/questions/26739167/jwt-json-web-token-automatic-prolongation-of-expiration - so it seems that this validates that the refresh ttl will force the user to log in again. I guess my question is whether there is a way to eliminate the refresh ttl completely using jwt-auth (otherwise I suppose I could set it for 10 years or so).
Thanks again for your assitance.

[jossemarGT]

Yes, as far as can see your approach is quite risky (because we use low ttl just in case that someone else "in the middle" took that token) but it might work as you expect, so, go on!

BTW Just to clarify a little bit more, you can see how does jwt-auth use the ttl and refresh_ttl here.

Happy coding :octocat:

[boriswexler]

Thanks again, this clears up all my questions.
I do believe that a feature allowing for turning off the refresh ttl would be useful as most mobile apps that don't handle super sensitive data never request refresh ttl. I'm going to ask Tymon if he'd be opposed to me adding that to the repo.

[tymondesigns]

@boriswexler Apologies for the late response. Looks like you have figured out the flow here then.

I will have a think about adding the "forever" option, as I appreciate your use case for it

@jossemarGT cheers for helping out

[boriswexler]

Thanks Sean - please let me know. I do think it would be very useful in
some scenarios.

On Tuesday, June 16, 2015, Sean Tymon [email protected] wrote:

@boriswexler https://github.com/boriswexler Apologies for the late
response. Looks like you have figured out the flow here then.

I will have a think about adding the "forever" option, as I appreciate
your use case for it

—
Reply to this email directly or view it on GitHub
https://github.com/tymondesigns/jwt-auth/issues/150#issuecomment-112548460
.

[CraigLovelock]

@tymondesigns Was the forever option ever implemented? thanks

[tdhsmith]

On develop/0.6 you can set 'ttl' => null and tokens will not expire.

[CraigLovelock]

@tdhsmith Makes sense, thanks :)