jsonwebtoken vs passport-jwt vs koa-passport vs koa-jwt
JWT Authentication Architecture in Node.js and Koa
Search packages..
jsonwebtokenpassport-jwtkoa-passportkoa-jwtSimilar Packages:

JWT Authentication Architecture in Node.js and Koa

jsonwebtoken is the core utility library for creating and verifying JSON Web Tokens. koa-jwt is dedicated middleware for protecting Koa routes using JWTs. passport-jwt is an authentication strategy for the Passport ecosystem, while koa-passport adapts Passport to work within Koa applications. Together, these packages represent different layers of the authentication stack, from low-level crypto operations to high-level framework integration.

Npm Package Weekly Downloads Trend

3 Years

Github Stars Ranking

Stat Detail

Package
Downloads
Stars
Size
Issues
Publish
License
jsonwebtoken32,025,35618,16143.4 kB1873 months agoMIT
passport-jwt2,331,0951,98552 kB43-MIT
koa-passport189,79477117.1 kB133 years agoMIT
koa-jwt66,5701,34943.2 kB6-MIT

JWT Authentication Architecture in Node.js and Koa

When securing Node.js applications, developers often face a choice between low-level control and high-level convenience. The packages jsonwebtoken, koa-jwt, koa-passport, and passport-jwt occupy different layers of this stack. jsonwebtoken handles the crypto operations, while the others provide integration paths for the Koa framework. Let's break down how they differ in practice.

🔐 Core Token Operations: Manual vs Automated

jsonwebtoken gives you direct access to sign and verify tokens.

  • You manage the HTTP headers and cookie logic yourself.
  • Best for custom setups or services that only issue tokens.
// jsonwebtoken: Manual signing and verifying
const jwt = require('jsonwebtoken');

// Signing
const token = jwt.sign({ userId: 123 }, 'SECRET_KEY', { expiresIn: '1h' });

// Verifying
try {
  const decoded = jwt.verify(token, 'SECRET_KEY');
  console.log(decoded.userId);
} catch (err) {
  console.error('Invalid token');
}

koa-jwt automates verification as middleware.

  • It checks the Authorization header automatically.
  • Attaches the decoded user data to ctx.state.
// koa-jwt: Automated middleware verification
const jwt = require('koa-jwt');

app.use(jwt({ secret: 'SECRET_KEY' }).unless({ path: ['/public'] }));

// In route handler
app.use(async (ctx) => {
  // ctx.state.user is populated automatically if valid
  ctx.body = { user: ctx.state.user };
});

passport-jwt defines a strategy for extracting and verifying tokens.

  • It focuses on the logic of finding the token and validating the user.
  • Does not run as middleware on its own without Passport.
// passport-jwt: Strategy definition
const JwtStrategy = require('passport-jwt').Strategy;

passport.use(new JwtStrategy({
  jwtFromRequest: ExtractJwt.fromAuthHeaderAsBearerToken(),
  secretOrKey: 'SECRET_KEY'
}, async (payload, done) => {
  const user = await findUser(payload.userId);
  return done(null, user);
}));

koa-passport connects Passport strategies to Koa's context.

  • It initializes Passport and runs the authentication middleware.
  • Bridges the gap between Express-style Passport and Koa.
// koa-passport: Running the strategy in Koa
const passport = require('koa-passport');

app.use(passport.initialize());

app.use(async (ctx, next) => {
  await passport.authenticate('jwt', { session: false })(ctx, next);
  // ctx.user is available after successful auth
});

🧩 Framework Integration: Dedicated vs Ecosystem

koa-jwt is built specifically for Koa.

  • It follows Koa's middleware patterns closely.
  • Less setup code if you only need JWTs.
// koa-jwt: Direct Koa integration
const Koa = require('koa');
const jwt = require('koa-jwt');
const app = new Koa();

app.use(jwt({ secret: 'SECRET_KEY' }));

koa-passport + passport-jwt relies on the broader Passport ecosystem.

  • Requires initializing Passport before using strategies.
  • More boilerplate but supports swapping strategies easily.
// koa-passport + passport-jwt: Ecosystem integration
const Koa = require('koa');
const passport = require('koa-passport');
const app = new Koa();

app.use(passport.initialize());
// Strategy configured separately as shown in previous section

jsonwebtoken has no framework integration.

  • You write the glue code to connect it to Koa or Express.
  • Maximum flexibility but more repetitive code.
// jsonwebtoken: Custom Koa integration
const jwt = require('jsonwebtoken');

app.use(async (ctx, next) => {
  const token = ctx.headers.authorization?.split(' ')[1];
  if (token) {
    try {
      ctx.state.user = jwt.verify(token, 'SECRET_KEY');
    } catch (e) {
      ctx.status = 401;
    }
  }
  await next();
});

🔄 Flexibility: Single Purpose vs Multi-Strategy

koa-jwt handles JWTs only.

  • If you need to add Google Login later, you must add another middleware.
  • Can lead to mixed authentication patterns in one app.
// koa-jwt: JWT only
app.use(jwt({ secret: 'SECRET_KEY' }));
// Adding OAuth requires a separate, unrelated middleware

passport-jwt works alongside other Passport strategies.

  • You can use passport-local for login and passport-jwt for API access.
  • Unified user loading logic across all methods.
// passport-jwt: Multi-strategy support
passport.use(new LocalStrategy(...)); // For login
passport.use(new JwtStrategy(...));    // For API access

// Same authentication interface for both
await passport.authenticate('local')(ctx, next);
await passport.authenticate('jwt')(ctx, next);

jsonwebtoken supports any strategy you code yourself.

  • You decide how to handle OAuth or API keys.
  • No built-in unification of user profiles.
// jsonwebtoken: Custom logic for everything
// You must manually write verification for each auth type
if (type === 'jwt') { /* verify jwt */ }
if (type === 'oauth') { /* verify oauth */ }

⚠️ Error Handling and Customization

koa-jwt has built-in error handling for invalid tokens.

  • Returns 401 Unauthorized by default.
  • Customizing error responses requires wrapping the middleware.
// koa-jwt: Default error handling
app.use(jwt({ secret: 'SECRET_KEY' }));
// Automatically throws 401 on failure

passport-jwt passes errors to the done callback.

  • Allows custom error messages or logging inside the strategy.
  • koa-passport handles the HTTP response based on strategy result.
// passport-jwt: Custom error logic
new JwtStrategy(opts, (payload, done) => {
  if (!payload.userId) return done(null, false);
  // Custom error handling
  return done(null, user);
});

jsonwebtoken throws standard JavaScript errors.

  • You catch TokenExpiredError or JsonWebTokenError.
  • Full control over the HTTP response status and body.
// jsonwebtoken: Manual error handling
try {
  jwt.verify(token, 'SECRET');
} catch (err) {
  if (err.name === 'TokenExpiredError') {
    ctx.status = 401;
    ctx.body = { error: 'Token expired' };
  }
}

📊 Summary Table

Featurejsonwebtokenkoa-jwtpassport-jwt + koa-passport
TypeUtility LibraryKoa MiddlewareStrategy + Adapter
SetupManualMinimalModerate
FlexibilityHighLow (JWT only)High (Multi-strategy)
User LoadingManualAutomatic (ctx.state)Automatic (ctx.user)
Best ForCustom LogicSimple Koa AppsComplex Auth Systems

💡 Final Recommendation

jsonwebtoken is the foundation. You will likely use it indirectly even if you choose the other options. Use it directly only if you are building a custom auth service or need to sign tokens outside of a request cycle.

koa-jwt is the pragmatic choice for microservices or simple APIs. If your app only needs JWT authentication and you want to avoid the weight of Passport, this is the most direct path. It keeps your codebase light and focused.

passport-jwt with koa-passport is the enterprise choice. If your application requires logging in via username/password, social providers, and API tokens simultaneously, Passport unifies these flows. It adds complexity, but it pays off when you need to manage multiple identity sources.

Final Thought: Start with koa-jwt for simplicity. Migrate to passport-jwt only if your authentication requirements grow beyond simple token verification. Use jsonwebtoken directly when you need to step outside the middleware lifecycle entirely.

How to Choose: jsonwebtoken vs passport-jwt vs koa-passport vs koa-jwt

  • jsonwebtoken:

    Choose jsonwebtoken if you need full control over token creation and verification logic without framework-specific middleware. It is ideal for custom authentication implementations, non-Koa environments, or when you need to sign tokens in a separate service.

  • passport-jwt:

    Choose passport-jwt if you need a standardized JWT strategy that integrates with Passport's session and user loading patterns. It works in tandem with koa-passport to provide a robust, ecosystem-backed authentication flow.

  • koa-passport:

    Choose koa-passport if you are already using the Passport ecosystem or need to support multiple authentication methods (like OAuth, Local, and JWT) within a Koa app. It is suitable for complex applications requiring flexible strategy management.

  • koa-jwt:

    Choose koa-jwt if you are building a Koa application that relies solely on JWT authentication and you prefer a simple, drop-in middleware solution. It is best for projects that value minimal configuration and do not require multiple authentication strategies.

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-jwt

passport-jwt is a Passport strategy for authenticating with JSON Web Tokens (JWT) in Node.js applications. It allows developers to easily implement JWT-based authentication in their Express applications, providing a straightforward way to secure routes and manage user sessions. By using passport-jwt, developers can ensure that only authenticated users can access certain resources, enhancing the security of their applications.

While passport-jwt is a robust solution for JWT authentication, there are other libraries that can also help manage JWTs in Node.js applications. Here are a few alternatives:

  • express-jwt is a middleware for Express applications that validates JWTs and automatically handles authentication. It checks the incoming requests for a valid JWT and denies access if the token is missing or invalid. express-jwt is a great choice for developers looking for a simple and effective way to secure their Express routes without the additional overhead of a full authentication framework like Passport. It is particularly useful for applications that require straightforward JWT validation without the need for user session management.

  • jsonwebtoken is a library that allows developers to sign, verify, and decode JSON Web Tokens. While it does not handle authentication directly, it provides the tools necessary to create and manage JWTs. Developers can use jsonwebtoken to generate tokens upon user login and verify them in subsequent requests. This library is ideal for those who want more control over the JWT lifecycle and prefer to implement their own authentication logic without relying on middleware.

To see how passport-jwt compares with express-jwt and jsonwebtoken, check out the comparison: Comparing express-jwt vs jsonwebtoken vs passport-jwt.

Similar Npm Packages to koa-jwt

koa-jwt is a middleware for Koa applications that helps implement JSON Web Token (JWT) authentication. It allows developers to protect routes by ensuring that incoming requests contain a valid JWT, providing a secure way to manage user authentication and authorization in web applications. While koa-jwt is a robust solution for JWT authentication, there are other libraries that can also facilitate similar functionalities. Here are a few alternatives:

  • jsonwebtoken is a widely used library for creating and verifying JSON Web Tokens. It provides methods to sign and verify tokens, making it a fundamental tool for any application that requires JWT authentication. While it doesn't directly integrate with Koa, it can be used alongside koa-jwt or other middleware to manage token creation and validation. If you need a library focused solely on handling JWTs without the Koa-specific integration, jsonwebtoken is a great choice.
  • koa-passport is a Koa middleware that integrates with the Passport authentication framework. It allows developers to implement various authentication strategies, including JWT, OAuth, and local authentication. While koa-jwt specifically focuses on JWT, koa-passport provides a more comprehensive solution for managing multiple authentication strategies in a Koa application. If your application requires flexibility in authentication methods, koa-passport is an excellent option.
  • passport-jwt is a Passport strategy for authenticating with a JSON Web Token. It works in conjunction with koa-passport or other Passport-based setups to provide JWT authentication. This library allows you to extract the JWT from the request and verify it, making it a suitable choice if you are already using Passport for authentication in your application. If you want to leverage Passport's extensive authentication capabilities while using JWT, passport-jwt is the way to go.

To see how koa-jwt compares with jsonwebtoken, koa-passport, and passport-jwt, check out the comparison: Comparing jsonwebtoken vs koa-jwt vs koa-passport vs passport-jwt.

README for jsonwebtoken

jsonwebtoken

BuildDependency
Build StatusDependency 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 ValueDigital Signature or MAC Algorithm
HS256HMAC using SHA-256 hash algorithm
HS384HMAC using SHA-384 hash algorithm
HS512HMAC using SHA-512 hash algorithm
RS256RSASSA-PKCS1-v1_5 using SHA-256 hash algorithm
RS384RSASSA-PKCS1-v1_5 using SHA-384 hash algorithm
RS512RSASSA-PKCS1-v1_5 using SHA-512 hash algorithm
PS256RSASSA-PSS using SHA-256 hash algorithm (only node ^6.12.0 OR >=8.0.0)
PS384RSASSA-PSS using SHA-384 hash algorithm (only node ^6.12.0 OR >=8.0.0)
PS512RSASSA-PSS using SHA-512 hash algorithm (only node ^6.12.0 OR >=8.0.0)
ES256ECDSA using P-256 curve and SHA-256 hash algorithm
ES384ECDSA using P-384 curve and SHA-384 hash algorithm
ES512ECDSA using P-521 curve and SHA-512 hash algorithm
noneNo 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, the official website for the npm registry. Note that npm is a registered trademark of npm, Inc. Please share your feedback via our GitHub repository. For more details, please refer to our Terms & Privacy.