Refresh token

[matiux]

Any ideas of how to implement the refresh token?

Seems nobody has written nothing...

[jfromaniello]

http://stackoverflow.com/questions/26739167/jwt-json-web-token-automatic-prolongation-of-expiration

[matiux]

OK thanks.

But some example of how to implement with node-jsonwebtoken?

[Sean-Wang]

+1

[nnur]

+1

[nnur]

is there a way to reissue the same token but just change the expiry date?

[morgondag]

kinda same as #133 but is there any official support to refresh a token?
Right now I validate the token and user data and then sends a new one to the client if it has expired,
but would rather just update the existing token.

    jwt.updateToken(token, data)

[mateeyow]

@morgondag I think your implementation is very dangerous since you are not assigning any expiration time to the token. It means that if some hacker gets the token, he/she can access your API indefinitely.

[morgondag]

@mateeyow sounds good, so what we are asking for is a way to update a token.
nothing is saying that we are nit doing any form of validation on it beforehand.

So there is no real way to update a token or change it expiry date without generating a new key.

I guess the best way is simply to force to user to login again and again and again :-/

[bookercodes]

I am also having trouble finding good information on:

• How to implement refresh tokens server-side
• A sensible strategy to refresh tokens on the client-side

[procedurallygenerated]

+1

[morgondag]

any progress?

[umair321]

you can verify user using previous token, then generate a new one for that user. Like:

 jsonwebtoken.verify(token, mySecret, function (err, user) {
            if (err) {
                return res.json(err);
            }
            if (user.id)
              res.json({
newToken: jwToken.issue({
                        id: user.id
                    })
});

        });

[jppellerin]

This is what I ended up doing on my end. My token is already verified by the time I hit my refresh function.

static refreshToken = (token): string => {
    let optionKeys = ['iat', 'exp', 'iss', 'sub'];
    let newToken;
    let obj = {};

    let now = Math.floor(Date.now()/1000);
    let timeToExpire = (token['exp'] - now);

    if (timeToExpire < (60 * 60)) { //1h
        for (let key in token) {
            if (optionKeys.indexOf(key) === -1) {
                obj[key] = token[key];
            }
        }

        let options = {
            expiresIn: '7 days',
            issuer: 'moi',
            subject: token.sub,
            algorithm: 'HS256'
        };

        newToken = JWT.sign(obj, Config.get('/jwtSecret'), options);
    }
    else {
        newToken = '';  //no need to refresh, do what you want here.
    }

    return newToken;
}

I don't refresh the token if it still has enough time to live. This may or may not be necessary, but saving a bit of calculation when not necessary.

Written in TypeScript, but the logic is the same. Should be generic enough to be used in many different circumstances.

[morgondag]

@jppellerin nice! would be nice to have that in the jwt api with a pull request <3

[jppellerin]

There's an idea... started working on it...

[jppellerin]

https://github.com/jppellerin/node-jsonwebtoken/tree/refresh-token

Refresh will work for a token that is decoded without the {complete: true} flag. Going to get that done eventually. Also only synchronous for the time being.

[Kiura]

@jppellerin, Hi, any news on the PR?

[jppellerin]

@Kiura Nothing yet. It's under pull request #172 waiting for review. You could comment on the pull request to help with getting it through in a timely manner.

[Kiura]

@jppellerin, thx for quick reply )

[Kiura]

And how about refresh token that never expires? Any idea how to implement and how it differs security wise?
Basically what I am trying to understand is whether to use refresh token that never expires, or use token and refresh the token every n minutes, and how it they should be refreshed?

here stackoverflow @jfromaniello says that it depends on the type of application what if I have to support web/mobile/native application?

[jppellerin]

A token that never expires doesn't need to be refreshed. From the docs :

If any expiresIn, notBeforeMinutes, audience, subject, issuer are not provided, there is no default. The jwt generated won't include those properties in the payload.

This means that if no expiresIn option is provided, your token will not expire.

As to the strategy that you use - that's a bit up to the design of your application. For example, we are building a web app and we don't want the token to live forever, nor do we want the user to be logged out mid-action when the token reaches it's expiry. Therefore, we refresh the token when the user is active. This means that our web app needs to be constantly updating the token on the front-end to ensure that they're always using the updated/refreshed version.

I've never done mobile, but assuming a similar strategy can be used.

Hope that helps.

[Kiura]

Thx again for your help, spent two days trying to figure out the best way. now I got something to start from.

[jppellerin]

@Kiura My pleasure. Good luck!

[mitchellporter]

Is there a reason that the PR hasn't been merged yet?

[DiegoZoracKy]

+1

[ZephD]

+1

[quangvo09]

+1

[alianrock]

+1 It's seem's like no one has get the best practise?

[bilarslan]

+1

[jppellerin]

@mitchellporter @alianrock It seems that the maintainers of the library haven't yet decided if they want this as part of their API (it seems to me that they don't).

Therefore it is pretty much left to the developer to implement it's own flavour of this. We have been using the code form pull request #172 for over a year in production.

[fiddur]

Fixed by documentation: #371

[bagdasaryanem]

@jppellerin Hi, if I understand correctly, is this PR applicable only to tokens that have not yet expired?