jsonwebtoken vs passport-jwt vs express-jwt

JWT Authentication in Node.js Backend Services

express-jwt, jsonwebtoken, and passport-jwt are all npm packages used to implement JSON Web Token (JWT) authentication in Node.js applications, but they serve different roles in the stack. jsonwebtoken is a low-level utility library for signing and verifying JWTs. express-jwt is a middleware specifically designed for Express.js that uses jsonwebtoken under the hood to protect routes by validating tokens. passport-jwt is a strategy plugin for the Passport authentication framework, enabling JWT-based authentication within Passport’s modular architecture. While all three deal with JWTs, their integration points, flexibility, and use cases differ significantly.

Package	Downloads	Stars	Size	Issues	Publish	License

jsonwebtoken	26,689,061	18,109	43.5 kB	185	2 years ago	MIT
passport-jwt	1,962,726	1,983	52 kB	41	-	MIT
express-jwt	593,448	4,515	28.5 kB	64	a year ago	MIT

JWT Handling in Node.js: express-jwt vs jsonwebtoken vs passport-jwt

When securing APIs with JSON Web Tokens (JWTs), developers often reach for one of three popular packages: express-jwt, jsonwebtoken, or passport-jwt. Though they all revolve around JWTs, they occupy very different layers of the authentication stack. Understanding their roles prevents architectural missteps — like using a full middleware when a simple utility suffices, or forcing Passport into a project that doesn’t need it.

🔑 Core Responsibilities: What Each Package Actually Does

jsonwebtoken is the raw toolkit. It provides two main functions: sign() to create tokens and verify() to validate them. It knows nothing about HTTP requests, Express, or user sessions — just cryptographic operations on JWT payloads.

// jsonwebtoken: manual token handling
const jwt = require('jsonwebtoken');

// Create a token
const token = jwt.sign({ userId: 123 }, 'secret-key', { expiresIn: '1h' });

// Verify a token (e.g., from Authorization header)
try {
  const payload = jwt.verify(token, 'secret-key');
  console.log('User ID:', payload.userId);
} catch (err) {
  console.error('Invalid token');
}

express-jwt wraps jsonwebtoken into an Express middleware. It automatically extracts the token (from Authorization: Bearer <token>, cookies, etc.), verifies it, and attaches the decoded payload to req.user. If verification fails, it sends a 401 error.

// express-jwt: automatic route protection
const express = require('express');
const jwt = require('express-jwt');

const app = express();

app.get('/protected',
  jwt({ secret: 'secret-key', algorithms: ['HS256'] }),
  (req, res) => {
    // req.user contains decoded payload
    res.json({ message: `Hello, user ${req.user.userId}` });
  }
);

passport-jwt is a strategy for Passport.js. It plugs into Passport’s authentication pipeline, allowing you to use passport.authenticate('jwt') as middleware. It relies on jsonwebtoken internally but fits into Passport’s broader model of strategies, serialization, and user lookup.

// passport-jwt: Passport integration
const JwtStrategy = require('passport-jwt').Strategy;
const ExtractJwt = require('passport-jwt').ExtractJwt;
const passport = require('passport');

const opts = {
  jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
  secretOrKey: 'secret-key'
};

passport.use(new JwtStrategy(opts, (payload, done) => {
  // Simulate user lookup
  if (payload.userId === 123) {
    return done(null, { id: payload.userId });
  }
  return done(null, false);
}));

// In route
app.get('/profile',
  passport.authenticate('jwt', { session: false }),
  (req, res) => {
    res.json({ user: req.user });
  }
);

🧩 Integration Depth: How Tightly Coupled Are They?

jsonwebtoken has zero coupling. You can use it in any JavaScript environment — CLI tools, AWS Lambda, Deno, or even frontend code (though signing secrets should never be exposed client-side). This makes it ideal for libraries or services that need portable JWT logic.

express-jwt is tightly bound to Express. It assumes you’re using Express middleware patterns and leverages Express’s error-handling flow. Trying to use it outside Express (e.g., with Fastify or Koa) won’t work without significant adaptation.

passport-jwt requires Passport as a peer dependency. If your app doesn’t already use Passport for other auth methods (like local login or OAuth), adding it just for JWTs introduces unnecessary abstraction. But if you do use Passport, this strategy keeps your auth code consistent.

⚙️ Customization: How Much Control Do You Get?

With jsonwebtoken, you control every step:

Where the token comes from
When and how it’s verified
How errors are handled
Whether to cache public keys for RS256

This is powerful but verbose. You’ll write more boilerplate for common tasks like extracting the Authorization header.

express-jwt offers moderate customization:

Define custom token extractors
Skip verification for certain paths
Handle errors via Express error middleware

But you can’t easily change how the payload becomes req.user — it’s always the raw decoded JWT unless you add another middleware to transform it.

passport-jwt gives you a callback (verify function) where you can:

Look up the user in a database
Attach full user objects (not just the JWT payload)
Reject tokens based on business logic (e.g., revoked tokens)

However, this happens after the JWT is cryptographically verified, so you can’t alter the verification itself — only decide whether to accept the user.

🛑 Error Handling: Who Catches the Mistakes?

In jsonwebtoken, errors are thrown as exceptions. You must wrap verify() in try/catch blocks or use callbacks. This gives you full control but requires discipline to avoid unhandled rejections.

// jsonwebtoken error handling
jwt.verify(token, 'secret', (err, decoded) => {
  if (err) {
    // Handle expired, invalid signature, etc.
    return res.status(401).json({ error: 'Unauthorized' });
  }
  // Proceed
});

express-jwt emits errors through Express’s error middleware. By default, it sends a 401 with { "message": "Unauthorized" }, but you can override this by defining an error handler:

// express-jwt custom error
app.use((err, req, res, next) => {
  if (err.name === 'UnauthorizedError') {
    res.status(401).json({ error: 'Custom unauthorized message' });
  }
});

passport-jwt passes errors to Passport’s internal flow. Failed authentications result in done(null, false) or done(err), which Passport translates into a 401 unless you customize the failure redirect or response.

🔄 Real-World Scenarios: Which One Fits?

Scenario 1: Simple API with Express

You’re building a REST API with Express and need to protect a few routes with JWTs issued by your own auth service.

✅ Best choice: express-jwt — minimal setup, automatic header parsing, clean integration.

Scenario 2: Microservice Verifying External Tokens

Your service receives JWTs from an identity provider (like Auth0) and needs to verify them using JWKS (public keys fetched dynamically).

✅ Best choice: jsonwebtoken — you’ll need to fetch and cache keys yourself, then call verify() with the correct key. Neither express-jwt nor passport-jwt handle JWKS natively without extra plugins.

Scenario 3: App with Multiple Auth Methods

Your app supports login via email/password, Google OAuth, and API tokens (JWTs), all managed through a single user model.

✅ Best choice: passport-jwt — it slots into Passport alongside passport-local and passport-google-oauth20, letting you use the same req.user and session logic everywhere.

🤝 Shared Foundation: They All Rely on jsonwebtoken

It’s worth noting that both express-jwt and passport-jwt depend on jsonwebtoken under the hood. They don’t reimplement JWT verification — they just wrap its functionality into specific architectural patterns. So if you understand jsonwebtoken, you understand the core mechanics of all three.

📊 Summary: When to Use Which

Concern	`jsonwebtoken`	`express-jwt`	`passport-jwt`
Use Case	Raw JWT operations	Express route protection	Passport.js integration
Framework Dependency	None	Express	Passport + Express
Control Level	Full	Medium	Medium (within Passport)
Boilerplate	High	Low	Medium
Best For	Libraries, custom flows	Simple Express APIs	Multi-strategy auth systems

💡 Final Recommendation

Start with jsonwebtoken if you’re unsure — it’s the foundation. Then layer on express-jwt or passport-jwt only if their abstractions genuinely simplify your code. Don’t adopt Passport just for JWTs, and don’t use express-jwt if you’re not on Express. Keep it simple — no jargon, no fluff.

jsonwebtoken:
Choose jsonwebtoken when you need full control over JWT creation and validation logic—such as custom signing algorithms, dynamic secret management, or non-Express environments. It’s the foundational library that powers higher-level abstractions, so use it directly when building custom auth flows, microservices, or frameworks where middleware wrappers add unnecessary overhead.
passport-jwt:
Choose passport-jwt if your application already uses Passport for authentication and you want to add JWT support while maintaining a consistent strategy interface across multiple auth methods (e.g., local, OAuth, JWT). It’s ideal for apps requiring unified user serialization/deserialization and session-less authentication within Passport’s ecosystem, but adds complexity if you don’t otherwise need Passport.
express-jwt:
Choose express-jwt if you're building an Express.js application and need a simple, drop-in middleware to protect routes with JWT validation. It handles token extraction from headers, cookies, or query parameters out of the box and integrates cleanly with Express error handling. Avoid it if you’re not using Express or need fine-grained control over the verification process beyond what its options provide.

jsonwebtoken

passport-jwt

express-jwt

jsonwebtoken

Build	Dependency

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.