jsonwebtoken vs passport vs @nestjs/passport vs express-jwt
Authentication Middleware Libraries Comparison
Search packages..
1 Year
jsonwebtokenpassport@nestjs/passportexpress-jwtSimilar Packages:
What's Authentication Middleware Libraries?

Authentication middleware libraries are essential tools in web development for managing user authentication and authorization. They provide mechanisms to secure applications by verifying user identities and controlling access to resources. These libraries facilitate the integration of various authentication strategies, such as JWT (JSON Web Tokens) and session-based authentication, making it easier for developers to implement secure authentication flows in their applications. They also help in managing user sessions and protecting routes, enhancing the overall security posture of web applications.

Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
jsonwebtoken18,914,61917,94143.5 kB1732 years agoMIT
passport3,430,80923,310157 kB390a year agoMIT
@nestjs/passport1,336,65053422.8 kB84 months agoMIT
express-jwt529,5764,50728.5 kB625 months agoMIT
Feature Comparison: jsonwebtoken vs passport vs @nestjs/passport vs express-jwt

Integration

  • jsonwebtoken:

    jsonwebtoken is a standalone library that can be used in any Node.js application. It does not depend on any framework, making it versatile for various use cases. Developers can use it to create and verify JWTs independently of the web framework being used.

  • passport:

    passport is a flexible authentication middleware for Node.js that supports a wide range of authentication strategies. Its modular design allows developers to easily add or remove strategies as needed, making it suitable for applications with diverse authentication requirements.

  • @nestjs/passport:

    @nestjs/passport integrates seamlessly with NestJS, leveraging its dependency injection and modular architecture. This integration allows developers to easily implement authentication strategies while adhering to NestJS conventions, making the codebase cleaner and more maintainable.

  • express-jwt:

    express-jwt is designed specifically for Express applications, providing a straightforward way to handle JWT authentication. It acts as middleware that can be easily plugged into existing Express routes, ensuring that token validation is handled efficiently without additional configuration.

Extensibility

  • jsonwebtoken:

    jsonwebtoken is highly extensible in terms of token creation and verification options. Developers can customize token payloads, expiration times, and signing algorithms, providing flexibility in how JWTs are managed within applications.

  • passport:

    passport is inherently extensible, supporting over 500 authentication strategies. Developers can easily add new strategies or modify existing ones, making it a powerful choice for applications requiring multiple authentication methods.

  • @nestjs/passport:

    @nestjs/passport is built on top of the Passport library, allowing developers to leverage existing Passport strategies while also creating custom strategies tailored to specific application needs. This extensibility makes it easy to adapt authentication mechanisms as requirements evolve.

  • express-jwt:

    express-jwt is focused on JWT validation and does not provide built-in extensibility for additional authentication strategies. However, it can be combined with other middleware for more complex authentication flows, allowing developers to extend functionality as needed.

Learning Curve

  • jsonwebtoken:

    jsonwebtoken is straightforward to use, with a simple API for creating and verifying tokens. Developers can quickly grasp its functionality, making it easy to integrate into applications without extensive learning.

  • passport:

    passport has a steeper learning curve due to its extensive features and multiple strategies. Developers need to understand how to configure and use different strategies, which can be complex for beginners. However, its flexibility and power make it worthwhile.

  • @nestjs/passport:

    The learning curve for @nestjs/passport is moderate, especially for developers familiar with NestJS. Understanding decorators, guards, and the overall NestJS architecture is essential, but the documentation and community support help ease the learning process.

  • express-jwt:

    express-jwt has a relatively low learning curve, as it focuses solely on JWT validation. Developers familiar with Express will find it easy to implement, requiring minimal setup and configuration to get started with token validation.

Performance

  • jsonwebtoken:

    jsonwebtoken performance is generally good, but it can vary based on the complexity of the token payload and the signing algorithm used. Developers should be mindful of performance implications when creating and verifying tokens, especially for large payloads.

  • passport:

    passport's performance can vary depending on the chosen strategy and how it is implemented. Some strategies may introduce additional overhead, so developers should consider performance implications when selecting and configuring strategies.

  • @nestjs/passport:

    @nestjs/passport offers good performance as it utilizes the underlying Passport library efficiently. The integration with NestJS allows for optimized handling of authentication flows, ensuring minimal overhead during request processing.

  • express-jwt:

    express-jwt is lightweight and optimized for performance, focusing solely on JWT validation. It processes requests quickly, making it suitable for applications where performance is critical, especially in high-traffic scenarios.

Security Features

  • jsonwebtoken:

    jsonwebtoken includes features for signing tokens securely and verifying their integrity. Developers can choose strong signing algorithms and manage token expiration, which are critical for maintaining security in token-based authentication.

  • passport:

    passport offers a wide range of security features through its various strategies. It supports secure session management, OAuth flows, and can be configured to handle different security concerns based on the selected authentication method.

  • @nestjs/passport:

    @nestjs/passport inherits security features from Passport, allowing for secure handling of authentication processes. It supports various strategies that include built-in security measures, such as CSRF protection and secure session management.

  • express-jwt:

    express-jwt provides robust security for JWT validation, ensuring that only valid tokens are accepted. It allows for customizable error handling and can be configured to enforce strict token validation rules, enhancing application security.

How to Choose: jsonwebtoken vs passport vs @nestjs/passport vs express-jwt
  • jsonwebtoken:

    Opt for jsonwebtoken if you need a library to create and verify JWT tokens directly. It is a standalone library that provides flexibility in handling JWTs, making it suitable for scenarios where you want to manage token creation and verification manually without relying on middleware.

  • passport:

    Use passport if you require a comprehensive authentication middleware that supports multiple strategies (e.g., local, OAuth, OpenID). It is highly extensible and allows for easy integration of various authentication mechanisms, making it a good choice for applications that need to support multiple login methods.

  • @nestjs/passport:

    Choose @nestjs/passport if you are developing a NestJS application and need a seamless integration with the Passport authentication middleware. It provides decorators and guards that simplify the implementation of various authentication strategies in a modular way.

  • express-jwt:

    Select express-jwt if you are specifically looking for a middleware to validate JWT tokens in your Express application. It is lightweight and focused solely on JWT authentication, making it ideal for applications that require token-based authentication without additional overhead.

Similar Npm Packages to jsonwebtoken

jsonwebtoken is a widely-used library for creating and verifying JSON Web Tokens (JWT) in Node.js applications. JWTs are a compact, URL-safe means of representing claims to be transferred between two parties. The jsonwebtoken library provides a simple API for signing and verifying tokens, making it a popular choice for authentication and authorization in web applications. It supports various algorithms for signing tokens and allows developers to easily manage user sessions and secure API endpoints.

While jsonwebtoken is a robust solution for handling JWTs, there are alternatives that cater to different needs:

  • jwt-decode is a lightweight library that focuses solely on decoding JWTs. Unlike jsonwebtoken, which can both sign and verify tokens, jwt-decode is used to extract the payload from a JWT without validating its signature. This can be useful when you need to read the claims contained in a token without requiring the secret key. If your application needs to read JWTs but does not require signing or verifying them, jwt-decode is a great choice.
  • jwt-simple is another library that provides a simple way to encode and decode JSON Web Tokens. It offers a minimalist API for creating and verifying tokens, focusing on simplicity and ease of use. While it does not support as many features as jsonwebtoken, such as advanced signature algorithms or token expiration handling, it can be a good option for projects that require a straightforward implementation of JWTs without the overhead of a more complex library.

To compare these libraries, check out the following link: Comparing jsonwebtoken vs jwt-decode vs jwt-simple.

Similar Npm Packages to passport

passport is an authentication middleware for Node.js applications, particularly those built with Express. It provides a simple and unobtrusive way to handle user authentication, supporting a wide range of authentication strategies, including local username and password, OAuth, OpenID, and more. Passport is designed to be flexible and modular, allowing developers to choose the authentication methods that best suit their applications.

While Passport is a robust solution for authentication, there are several alternatives that can be used for various aspects of user authentication and session management. Here are a few notable alternatives:

  • bcrypt is a library used for hashing passwords. It is commonly used in conjunction with authentication libraries like Passport to securely store user passwords. Bcrypt employs a strong hashing algorithm that makes it difficult for attackers to retrieve the original password, even if they gain access to the hashed version. If your primary concern is securely handling user passwords, bcrypt is an essential tool to incorporate into your authentication workflow.

  • express-session is a middleware for managing user sessions in Express applications. It allows you to store session data on the server side and associate it with a unique session ID stored in a cookie on the client side. While Passport handles authentication, express-session can be used to maintain user sessions after authentication has occurred. This is particularly useful for applications that require user login persistence across multiple requests.

  • jsonwebtoken is a library for creating and verifying JSON Web Tokens (JWT). JWTs are a popular method for handling authentication in modern web applications, allowing for stateless authentication. When used with Passport, jsonwebtoken can provide a way to issue tokens after successful authentication, enabling secure communication between the client and server without the need for session storage. If your application requires a stateless authentication mechanism, jsonwebtoken is a great alternative to consider.

To explore how these packages compare, check out the comparison: Comparing bcrypt vs express-session vs jsonwebtoken vs passport.

Similar Npm Packages to @nestjs/passport

@nestjs/passport is a powerful authentication library designed specifically for NestJS applications. It integrates seamlessly with the Passport authentication middleware, providing a robust framework for implementing various authentication strategies in your NestJS projects. With @nestjs/passport, developers can easily manage user authentication, ensuring secure access to resources within their applications. The library supports a wide range of authentication strategies, including local, JWT, OAuth, and more, making it a versatile choice for developers looking to implement authentication in their NestJS applications.

While @nestjs/passport is a great option for NestJS applications, there are several alternatives that can also be considered for authentication in Node.js applications:

  • express-jwt is a middleware for Express.js applications that validates JSON Web Tokens (JWT). It is designed to work with any Express application and provides a simple way to protect routes by ensuring that incoming requests contain a valid JWT. If you are using JWT for authentication in your Express app, express-jwt is a straightforward solution that integrates easily with your existing middleware stack.
  • jsonwebtoken is a library for creating and verifying JSON Web Tokens. While it does not provide middleware like express-jwt, it is a fundamental library for working with JWTs in Node.js applications. Developers can use jsonwebtoken to generate tokens, sign them, and verify their authenticity. If you need low-level control over JWT creation and verification without the additional overhead of middleware, jsonwebtoken is a solid choice.
  • passport is a popular authentication middleware for Node.js applications. It provides a comprehensive set of strategies for various authentication methods, including local authentication, OAuth, OpenID, and more. Passport is highly flexible and can be used with any Node.js framework, including Express and NestJS. If you are looking for a mature and widely adopted authentication solution with extensive community support, Passport is an excellent option.

To compare these packages, check out the following link: Comparing @nestjs/passport vs express-jwt vs jsonwebtoken vs passport.

Similar Npm Packages to express-jwt

express-jwt is a middleware for Express.js that allows you to authenticate JSON Web Tokens (JWT) in your Node.js applications. It simplifies the process of securing your API endpoints by verifying the token sent in the request headers and ensuring that the user is authenticated before granting access to protected resources. This package is particularly useful in applications that require user authentication and authorization, making it a popular choice among developers.

However, there are several alternatives to express-jwt that also provide JWT authentication and authorization capabilities:

  • express-jwt-authz is an authorization middleware for Express.js that works in conjunction with express-jwt. While express-jwt handles authentication by verifying the token, express-jwt-authz focuses on authorization by checking if the authenticated user has the necessary permissions to access specific resources. This package is ideal for applications that require fine-grained access control based on user roles and permissions.

  • jsonwebtoken is a widely-used library for creating and verifying JWTs. While it is not a middleware like express-jwt, it provides the core functionality needed to generate and decode JWTs. Developers often use jsonwebtoken in conjunction with express-jwt to create and verify tokens, making it a fundamental part of the JWT ecosystem in Node.js applications.

  • jwt-simple is another lightweight library for encoding and decoding JWTs. It provides a simple API for working with JWTs, making it easy to integrate into your applications. While it lacks some of the advanced features of jsonwebtoken, jwt-simple is a good choice for developers looking for a minimalistic solution for handling JWTs.

  • koa-jwt is a middleware for Koa.js, similar to express-jwt but specifically designed for the Koa framework. It provides JWT authentication capabilities for Koa applications, allowing developers to secure their APIs with ease. If you are using Koa instead of Express, koa-jwt is the go-to option for handling JWT authentication.

  • passport-jwt is a strategy for the Passport authentication middleware that allows you to authenticate users using JWTs. It integrates seamlessly with the Passport framework, making it a suitable choice for applications that already use Passport for authentication. This package provides a robust solution for managing user authentication with JWTs in a modular way.

To explore how express-jwt compares with its alternatives, check out the comparison: Comparing express-jwt vs express-jwt-authz vs jsonwebtoken vs jwt-simple vs koa-jwt vs passport-jwt.

README for jsonwebtoken

jsonwebtoken

| Build | Dependency | |-----------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------| | Build Status | Dependency Status |

An implementation of JSON Web Tokens.

This was developed against draft-ietf-oauth-json-web-token-08. It makes use of node-jws

Install

$ npm install jsonwebtoken

Migration notes

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), 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.

    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.

    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)

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)

var jwt = require('jsonwebtoken');
var token = jwt.sign({ foo: 'bar' }, 'shhhhh');

Synchronous Sign with RSA SHA256

// sign with RSA SHA256
var privateKey = fs.readFileSync('private.key');
var token = jwt.sign({ foo: 'bar' }, privateKey, { algorithm: 'RS256' });

Sign asynchronously

jwt.sign({ foo: 'bar' }, privateKey, { algorithm: 'RS256' }, function(err, token) {
  console.log(token);
});

Backdate a jwt 30 seconds

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:

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:

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, 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.

    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)
  • 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.
// 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
});
Need to peek into a JWT without verifying it? (Click to expand)

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

// 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)

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]
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]'
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
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 to show how this could be accomplished. Apart from that example there are an issue and a pull request 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 details the procedure for disclosing security issues.

Author

Auth0

License

This project is licensed under the MIT license. See the LICENSE file for more info.

npm-compare.com is an independent website designed to help developers choose the most suitable npm packages. We are not affiliated with npm, Inc or npmjs.com, the official website for the npm registry. Please note that npm is a registered trademark of npm, Inc. For more details, please refer to our Terms & Privacy.