Added API endpoint for token refresh#172
Conversation
…e {complete: true} option is on
…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
|
+1 |
1 similar comment
|
+1 |
|
Very nice job, I will merge this! |
|
👍 Excellent! Thank you! |
|
Quick question, when will this be merged? Any ETA? |
|
+1 |
|
+1 Any news on when is this being implemented? |
|
@mateeyow @arturskeeled I'm not sure when the next major release will be coming out, but I have just updated my forked version with the refresh endpoint : https://github.com/jppellerin/node-jsonwebtoken. You could use this for development purposes. Disclaimer: I have not tested the merge thoroughly.. |
|
Waiting for this to get released |
|
When is the next major release for this ? |
|
👍 we'd really like to implement refresh tokens. |
|
Any ETA yet? |
|
Bump... |
|
Last bump. I don't want to fork but I really need this. |
|
@RWOverdijk : I have just updated my fork with the newest version and fixed the tests. I can keep this up to date with the newest features here until it gets merged in. If you want some assurances, I can tag you a version. That's the best I can do. |
|
Is there a reason this hasn't been merged yet? |
|
forking is the place. |
|
Now you can use this? |
|
I am still considering this feature, I think as it is it doesn't add too much value over |
|
@jfromaniello Thanks for the feedback. The goal (for what we are using it for) is to extract all fields of a token and return it with a new I didn't include verification since the token needs to be decoded for this to work. Therefore, it assumes the user has manipulated this - thus it would be safe to assume that it has been validated. I agree that if one uses this API the wrong way and refreshes a non-valid JWT, then a valid one will be returned, which has cause for concern. The value this endpoint has is to save the logic of copying over the fields of the existing token and re-signing it. I can agree with you that it is not something extremely difficult to do, but is something that is useful and that many people are using (or so it seems by the interest of this pull request). I would assume that this is going to be more and more common as people are moving towards serverless architectures/completely stateless. All that being said: I think that verification would be a good idea. I also think it is a useful endpoint (I may be biased since I'm using this). |
| ```js | ||
| // ... | ||
| var originalDecoded = jwt.decode(token, {complete: true}); | ||
| var refreshed = jwt.refresh(originalDecoded, 3600, secret); |
There was a problem hiding this comment.
I think it should be var refreshed = jwt.refresh(**token**, 3600, secret);
There was a problem hiding this comment.
I don't see the point of this. You have to decode and validate it, and you will have the payload, why not just call sign on that payload instead of having a refresh function that will decode it again?
|
@jfromaniello Maybe this pull request should be rejected if it's not going to be merged? It has been over a year now. |
|
@jppellerin can you give me an example to use it ? |
|
Whats the update on this pull request? It's been over a year. I agree with @jppellerin that it should either get merged if not rejected. @jppellerin Have you considered making a fork of this and pushing to npm? |
|
@fiftysoft : An example is in the readme docs of the pull request. @ndaljr : I have considered making a fork, but the problem is keeping up with the rest of the library. I don't want to have the code duplicated and potentially falling behind on updates. If this was to become it's own module, it would have to only extend it. Which, I might put some thought into this. |
|
Any status on this? |
|
Fixed by documentation: #371 |
|
Well this feels like a big slap in the face for the people who were waiting for it. |
|
@VMBindraban: Since you still had to decode and validate it before using the refresh function, that function added very little value over just deleting old exp/iat and using sign instead. Keeping the API and the code clean and small without unnecessary complexity is more important than a convenience method that is hardly even convenient. |
|
I have found a problem in the refresh function that's causing it to generate the same token. |
|
What if the original token gets stolen? |
|
Then you call the police. Theft is not okay.
|
|
I mean this feature could pose a security issue if any app is using it. There's no point in making it expire only in first place. |
|
You're commenting on an issue from 2016 dude. But to answer your question: every form of session/auth has the same issue. Cookies: get the token. JWT: get the token. oauth: get the token. Just make it really really difficult to steal the token. 😄 |
|
Ok you just think why do we set an expiry to the token in first place and why do we have two different types of token. |
|
This is a very old issue and every one was asking why feature wasn't merged. Thought this could be a reason. |
# jsonwebtoken | **Build** | **Dependency** | |-----------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------| | [](http://travis-ci.org/auth0/node-jsonwebtoken) | [](https://david-dm.org/auth0/node-jsonwebtoken) | An implementation of [JSON Web Tokens](https://tools.ietf.org/html/rfc7519). This was developed against `draft-ietf-oauth-json-web-token-08`. It makes use of [node-jws](https://github.com/brianloveswords/node-jws) # Install ```bash $ npm install jsonwebtoken ``` # Migration notes * [From v8 to v9](https://github.com/auth0/node-jsonwebtoken/wiki/Migration-Notes:-v8-to-v9) * [From v7 to v8](https://github.com/auth0/node-jsonwebtoken/wiki/Migration-Notes:-v7-to-v8) # Usage ### jwt.sign(payload, secretOrPrivateKey, [options, callback]) (Asynchronous) If a callback is supplied, the callback is called with the `err` or the JWT. (Synchronous) Returns the JsonWebToken as string `payload` could be an object literal, buffer or string representing valid JSON. > **Please _note_ that** `exp` or any other claim is only set if the payload is an object literal. Buffer or string payloads are not checked for JSON validity. > If `payload` is not a buffer or a string, it will be coerced into a string using `JSON.stringify`. `secretOrPrivateKey` is a string (utf-8 encoded), buffer, object, or KeyObject containing either the secret for HMAC algorithms or the PEM encoded private key for RSA and ECDSA. In case of a private key with passphrase an object `{ key, passphrase }` can be used (based on [crypto documentation](https://nodejs.org/api/crypto.html#crypto_sign_sign_private_key_output_format)), in this case be sure you pass the `algorithm` option. When signing with RSA algorithms the minimum modulus length is 2048 except when the allowInsecureKeySizes option is set to true. Private keys below this size will be rejected with an error. `options`: * `algorithm` (default: `HS256`) * `expiresIn`: expressed in seconds or a string describing a time span [vercel/ms](https://github.com/vercel/ms). > Eg: `60`, `"2 days"`, `"10h"`, `"7d"`. A numeric value is interpreted as a seconds count. If you use a string be sure you provide the time units (days, hours, etc), otherwise milliseconds unit is used by default (`"120"` is equal to `"120ms"`). * `notBefore`: expressed in seconds or a string describing a time span [vercel/ms](https://github.com/vercel/ms). > Eg: `60`, `"2 days"`, `"10h"`, `"7d"`. A numeric value is interpreted as a seconds count. If you use a string be sure you provide the time units (days, hours, etc), otherwise milliseconds unit is used by default (`"120"` is equal to `"120ms"`). * `audience` * `issuer` * `jwtid` * `subject` * `noTimestamp` * `header` * `keyid` * `mutatePayload`: if true, the sign function will modify the payload object directly. This is useful if you need a raw reference to the payload after claims have been applied to it but before it has been encoded into a token. * `allowInsecureKeySizes`: if true allows private keys with a modulus below 2048 to be used for RSA * `allowInvalidAsymmetricKeyTypes`: if true, allows asymmetric keys which do not match the specified algorithm. This option is intended only for backwards compatability and should be avoided. > There are no default values for `expiresIn`, `notBefore`, `audience`, `subject`, `issuer`. These claims can also be provided in the payload directly with `exp`, `nbf`, `aud`, `sub` and `iss` respectively, but you **_can't_** include in both places. Remember that `exp`, `nbf` and `iat` are **NumericDate**, see related [Token Expiration (exp claim)](#token-expiration-exp-claim) The header can be customized via the `options.header` object. Generated jwts will include an `iat` (issued at) claim by default unless `noTimestamp` is specified. If `iat` is inserted in the payload, it will be used instead of the real timestamp for calculating other things like `exp` given a timespan in `options.expiresIn`. Synchronous Sign with default (HMAC SHA256) ```js var jwt = require('jsonwebtoken'); var token = jwt.sign({ foo: 'bar' }, 'shhhhh'); ``` Synchronous Sign with RSA SHA256 ```js // sign with RSA SHA256 var privateKey = fs.readFileSync('private.key'); var token = jwt.sign({ foo: 'bar' }, privateKey, { algorithm: 'RS256' }); ``` Sign asynchronously ```js jwt.sign({ foo: 'bar' }, privateKey, { algorithm: 'RS256' }, function(err, token) { console.log(token); }); ``` Backdate a jwt 30 seconds ```js var older_token = jwt.sign({ foo: 'bar', iat: Math.floor(Date.now() / 1000) - 30 }, 'shhhhh'); ``` #### Token Expiration (exp claim) The standard for JWT defines an `exp` claim for expiration. The expiration is represented as a **NumericDate**: > A JSON numeric value representing the number of seconds from 1970-01-01T00:00:00Z UTC until the specified UTC date/time, ignoring leap seconds. This is equivalent to the IEEE Std 1003.1, 2013 Edition [POSIX.1] definition "Seconds Since the Epoch", in which each day is accounted for by exactly 86400 seconds, other than that non-integer values can be represented. See RFC 3339 [RFC3339] for details regarding date/times in general and UTC in particular. This means that the `exp` field should contain the number of seconds since the epoch. Signing a token with 1 hour of expiration: ```javascript jwt.sign({ exp: Math.floor(Date.now() / 1000) + (60 * 60), data: 'foobar' }, 'secret'); ``` Another way to generate a token like this with this library is: ```javascript jwt.sign({ data: 'foobar' }, 'secret', { expiresIn: 60 * 60 }); //or even better: jwt.sign({ data: 'foobar' }, 'secret', { expiresIn: '1h' }); ``` ### jwt.verify(token, secretOrPublicKey, [options, callback]) (Asynchronous) If a callback is supplied, function acts asynchronously. The callback is called with the decoded payload if the signature is valid and optional expiration, audience, or issuer are valid. If not, it will be called with the error. (Synchronous) If a callback is not supplied, function acts synchronously. Returns the payload decoded if the signature is valid and optional expiration, audience, or issuer are valid. If not, it will throw the error. > __Warning:__ When the token comes from an untrusted source (e.g. user input or external requests), the returned decoded payload should be treated like any other user input; please make sure to sanitize and only work with properties that are expected `token` is the JsonWebToken string `secretOrPublicKey` is a string (utf-8 encoded), buffer, or KeyObject containing either the secret for HMAC algorithms, or the PEM encoded public key for RSA and ECDSA. If `jwt.verify` is called asynchronous, `secretOrPublicKey` can be a function that should fetch the secret or public key. See below for a detailed example As mentioned in [this comment](auth0/node-jsonwebtoken#208 (comment)), there are other libraries that expect base64 encoded secrets (random bytes encoded using base64), if that is your case you can pass `Buffer.from(secret, 'base64')`, by doing this the secret will be decoded using base64 and the token verification will use the original random bytes. `options` * `algorithms`: List of strings with the names of the allowed algorithms. For instance, `["HS256", "HS384"]`. > If not specified a defaults will be used based on the type of key provided > * secret - ['HS256', 'HS384', 'HS512'] > * rsa - ['RS256', 'RS384', 'RS512'] > * ec - ['ES256', 'ES384', 'ES512'] > * default - ['RS256', 'RS384', 'RS512'] * `audience`: if you want to check audience (`aud`), provide a value here. The audience can be checked against a string, a regular expression or a list of strings and/or regular expressions. > Eg: `"urn:foo"`, `/urn:f[o]{2}/`, `[/urn:f[o]{2}/, "urn:bar"]` * `complete`: return an object with the decoded `{ payload, header, signature }` instead of only the usual content of the payload. * `issuer` (optional): string or array of strings of valid values for the `iss` field. * `jwtid` (optional): if you want to check JWT ID (`jti`), provide a string value here. * `ignoreExpiration`: if `true` do not validate the expiration of the token. * `ignoreNotBefore`... * `subject`: if you want to check subject (`sub`), provide a value here * `clockTolerance`: number of seconds to tolerate when checking the `nbf` and `exp` claims, to deal with small clock differences among different servers * `maxAge`: the maximum allowed age for tokens to still be valid. It is expressed in seconds or a string describing a time span [vercel/ms](https://github.com/vercel/ms). > Eg: `1000`, `"2 days"`, `"10h"`, `"7d"`. A numeric value is interpreted as a seconds count. If you use a string be sure you provide the time units (days, hours, etc), otherwise milliseconds unit is used by default (`"120"` is equal to `"120ms"`). * `clockTimestamp`: the time in seconds that should be used as the current time for all necessary comparisons. * `nonce`: if you want to check `nonce` claim, provide a string value here. It is used on Open ID for the ID Tokens. ([Open ID implementation notes](https://openid.net/specs/openid-connect-core-1_0.html#NonceNotes)) * `allowInvalidAsymmetricKeyTypes`: if true, allows asymmetric keys which do not match the specified algorithm. This option is intended only for backwards compatability and should be avoided. ```js // verify a token symmetric - synchronous var decoded = jwt.verify(token, 'shhhhh'); console.log(decoded.foo) // bar // verify a token symmetric jwt.verify(token, 'shhhhh', function(err, decoded) { console.log(decoded.foo) // bar }); // invalid token - synchronous try { var decoded = jwt.verify(token, 'wrong-secret'); } catch(err) { // err } // invalid token jwt.verify(token, 'wrong-secret', function(err, decoded) { // err // decoded undefined }); // verify a token asymmetric var cert = fs.readFileSync('public.pem'); // get public key jwt.verify(token, cert, function(err, decoded) { console.log(decoded.foo) // bar }); // verify audience var cert = fs.readFileSync('public.pem'); // get public key jwt.verify(token, cert, { audience: 'urn:foo' }, function(err, decoded) { // if audience mismatch, err == invalid audience }); // verify issuer var cert = fs.readFileSync('public.pem'); // get public key jwt.verify(token, cert, { audience: 'urn:foo', issuer: 'urn:issuer' }, function(err, decoded) { // if issuer mismatch, err == invalid issuer }); // verify jwt id var cert = fs.readFileSync('public.pem'); // get public key jwt.verify(token, cert, { audience: 'urn:foo', issuer: 'urn:issuer', jwtid: 'jwtid' }, function(err, decoded) { // if jwt id mismatch, err == invalid jwt id }); // verify subject var cert = fs.readFileSync('public.pem'); // get public key jwt.verify(token, cert, { audience: 'urn:foo', issuer: 'urn:issuer', jwtid: 'jwtid', subject: 'subject' }, function(err, decoded) { // if subject mismatch, err == invalid subject }); // alg mismatch var cert = fs.readFileSync('public.pem'); // get public key jwt.verify(token, cert, { algorithms: ['RS256'] }, function (err, payload) { // if token alg != RS256, err == invalid signature }); // Verify using getKey callback // Example uses https://github.com/auth0/node-jwks-rsa as a way to fetch the keys. var jwksClient = require('jwks-rsa'); var client = jwksClient({ jwksUri: 'https://sandrino.auth0.com/.well-known/jwks.json' }); function getKey(header, callback){ client.getSigningKey(header.kid, function(err, key) { var signingKey = key.publicKey || key.rsaPublicKey; callback(null, signingKey); }); } jwt.verify(token, getKey, options, function(err, decoded) { console.log(decoded.foo) // bar }); ``` <details> <summary><em></em>Need to peek into a JWT without verifying it? (Click to expand)</summary> ### jwt.decode(token [, options]) (Synchronous) Returns the decoded payload without verifying if the signature is valid. > __Warning:__ This will __not__ verify whether the signature is valid. You should __not__ use this for untrusted messages. You most likely want to use `jwt.verify` instead. > __Warning:__ When the token comes from an untrusted source (e.g. user input or external request), the returned decoded payload should be treated like any other user input; please make sure to sanitize and only work with properties that are expected `token` is the JsonWebToken string `options`: * `json`: force JSON.parse on the payload even if the header doesn't contain `"typ":"JWT"`. * `complete`: return an object with the decoded payload and header. Example ```js // get the decoded payload ignoring signature, no secretOrPrivateKey needed var decoded = jwt.decode(token); // get the decoded payload and header var decoded = jwt.decode(token, {complete: true}); console.log(decoded.header); console.log(decoded.payload) ``` </details> ## Errors & Codes Possible thrown errors during verification. Error is the first argument of the verification callback. ### TokenExpiredError Thrown error if the token is expired. Error object: * name: 'TokenExpiredError' * message: 'jwt expired' * expiredAt: [ExpDate] ```js jwt.verify(token, 'shhhhh', function(err, decoded) { if (err) { /* err = { name: 'TokenExpiredError', message: 'jwt expired', expiredAt: 1408621000 } */ } }); ``` ### JsonWebTokenError Error object: * name: 'JsonWebTokenError' * message: * 'invalid token' - the header or payload could not be parsed * 'jwt malformed' - the token does not have three components (delimited by a `.`) * 'jwt signature is required' * 'invalid signature' * 'jwt audience invalid. expected: [OPTIONS AUDIENCE]' * 'jwt issuer invalid. expected: [OPTIONS ISSUER]' * 'jwt id invalid. expected: [OPTIONS JWT ID]' * 'jwt subject invalid. expected: [OPTIONS SUBJECT]' ```js jwt.verify(token, 'shhhhh', function(err, decoded) { if (err) { /* err = { name: 'JsonWebTokenError', message: 'jwt malformed' } */ } }); ``` ### NotBeforeError Thrown if current time is before the nbf claim. Error object: * name: 'NotBeforeError' * message: 'jwt not active' * date: 2018-10-04T16:10:44.000Z ```js jwt.verify(token, 'shhhhh', function(err, decoded) { if (err) { /* err = { name: 'NotBeforeError', message: 'jwt not active', date: 2018-10-04T16:10:44.000Z } */ } }); ``` ## Algorithms supported Array of supported algorithms. The following algorithms are currently supported. | alg Parameter Value | Digital Signature or MAC Algorithm | |---------------------|------------------------------------------------------------------------| | HS256 | HMAC using SHA-256 hash algorithm | | HS384 | HMAC using SHA-384 hash algorithm | | HS512 | HMAC using SHA-512 hash algorithm | | RS256 | RSASSA-PKCS1-v1_5 using SHA-256 hash algorithm | | RS384 | RSASSA-PKCS1-v1_5 using SHA-384 hash algorithm | | RS512 | RSASSA-PKCS1-v1_5 using SHA-512 hash algorithm | | PS256 | RSASSA-PSS using SHA-256 hash algorithm (only node ^6.12.0 OR >=8.0.0) | | PS384 | RSASSA-PSS using SHA-384 hash algorithm (only node ^6.12.0 OR >=8.0.0) | | PS512 | RSASSA-PSS using SHA-512 hash algorithm (only node ^6.12.0 OR >=8.0.0) | | ES256 | ECDSA using P-256 curve and SHA-256 hash algorithm | | ES384 | ECDSA using P-384 curve and SHA-384 hash algorithm | | ES512 | ECDSA using P-521 curve and SHA-512 hash algorithm | | none | No digital signature or MAC value included | ## Refreshing JWTs First of all, we recommend you to think carefully if auto-refreshing a JWT will not introduce any vulnerability in your system. We are not comfortable including this as part of the library, however, you can take a look at [this example](https://gist.github.com/ziluvatar/a3feb505c4c0ec37059054537b38fc48) to show how this could be accomplished. Apart from that example there are [an issue](auth0/node-jsonwebtoken#122) and [a pull request](auth0/node-jsonwebtoken#172) to get more knowledge about this topic. # TODO * X.509 certificate chain is not checked ## Issue Reporting If you have found a bug or if you have a feature request, please report them at this repository issues section. Please do not report security vulnerabilities on the public GitHub issue tracker. The [Responsible Disclosure Program](https://auth0.com/whitehat) details the procedure for disclosing security issues. ## Author [Auth0](https://auth0.com) ## License This project is licensed under the MIT license. See the [LICENSE](LICENSE) file for more info.
](http://travis-ci.org/auth0/node-jsonwebtoken){kind=link}
](https://david-dm.org/auth0/node-jsonwebtoken){kind=link}
20 participants
According to issue #122, there was some interest in having an endpoint to refresh a token.
A refresh is considered to have the same token returned, but with a later expiry time.
This function takes in a decoded token, copies the attributes of this token over, and with that data, proceeds to signing a new token. The only piece of data that is replaced is the
expiresInvalue, which is passed in the function parameters. By extension, theiatvalue is also changed since a new token is created.