Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Refresh token #122

Closed
matiux opened this issue Aug 26, 2015 · 32 comments
Closed

Refresh token #122

matiux opened this issue Aug 26, 2015 · 32 comments

Comments

@matiux
Copy link

matiux commented Aug 26, 2015

Any ideas of how to implement the refresh token?

Seems nobody has written nothing...

@jfromaniello
Copy link
Member

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

@matiux
Copy link
Author

matiux commented Aug 26, 2015

OK thanks.

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

@Sean-Wang
Copy link

+1

1 similar comment
@nnur
Copy link

nnur commented Oct 14, 2015

+1

@nnur
Copy link

nnur commented Oct 14, 2015

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

@morgondag
Copy link

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
Copy link

@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
Copy link

@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
Copy link

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
Copy link

+1

@morgondag
Copy link

any progress?

@umair321
Copy link

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
Copy link

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
Copy link

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

@jppellerin
Copy link

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

@jppellerin
Copy link

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.

jppellerin pushed a commit to jppellerin/node-jsonwebtoken that referenced this issue Feb 3, 2016
…dpoint to refresh a token. A refresh is considered to have the same token returned, but with a later expiry time.

Can take into account the header + payload of a decoded token ie : {complete: true}

More in depth testing with comparision of equality

Testing failures and async mode

Added description for refresh in README.md
@Kiura
Copy link

Kiura commented Feb 4, 2016

@jppellerin, Hi, any news on the PR?

@jppellerin
Copy link

@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
Copy link

Kiura commented Feb 4, 2016

@jppellerin, thx for quick reply )

@Kiura
Copy link

Kiura commented Feb 4, 2016

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
Copy link

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
Copy link

Kiura commented Feb 4, 2016

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

@jppellerin
Copy link

@Kiura My pleasure. Good luck!

@mitchellporter
Copy link

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

@DiegoZoracKy
Copy link

+1

2 similar comments
@ZephD
Copy link

ZephD commented Nov 7, 2016

+1

@quangvo09
Copy link

+1

@alianrock
Copy link

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

@bilarslan
Copy link

+1

@jppellerin
Copy link

@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
Copy link
Contributor

fiddur commented Jul 14, 2017

Fixed by documentation: #371

@bagdasaryanem
Copy link

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests