jsonwebtoken vs passport-jwt vs koa-passport vs koa-jwt
JWT Authentication Libraries for Node.js Comparison
Search packages..
1 Year
jsonwebtokenpassport-jwtkoa-passportkoa-jwtSimilar Packages:
What's JWT Authentication Libraries for Node.js?

These libraries facilitate JSON Web Token (JWT) authentication in Node.js applications, providing mechanisms for secure user authentication and session management. They help developers implement token-based authentication strategies, which are essential for modern web applications that require stateless authentication. Each library serves a specific purpose within the authentication flow, from token creation to middleware integration, enhancing security and user experience.

Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
jsonwebtoken18,551,98317,86943.5 kB1712 years agoMIT
passport-jwt1,287,8211,97752 kB42-MIT
koa-passport224,29977417.1 kB132 years agoMIT
koa-jwt45,7101,34743.2 kB7-MIT
Feature Comparison: jsonwebtoken vs passport-jwt vs koa-passport vs koa-jwt

Token Creation and Verification

  • jsonwebtoken:

    jsonwebtoken provides functions to create and verify JWTs easily. It allows developers to sign tokens with a secret or private key and verify them against the same key, ensuring the integrity and authenticity of the tokens. This library supports various algorithms for signing, giving flexibility in securing tokens.

  • passport-jwt:

    passport-jwt provides a strategy for Passport.js that allows for JWT verification. It works in conjunction with Passport's authentication flow, enabling the use of JWTs as a means of authenticating users in applications that already utilize Passport for other strategies.

  • koa-passport:

    koa-passport does not directly handle token creation or verification. Instead, it integrates with other strategies (like passport-jwt) to manage authentication flows, allowing you to use JWTs as part of a broader authentication strategy that can include sessions and other methods.

  • koa-jwt:

    koa-jwt does not create tokens itself; instead, it focuses on verifying JWTs in incoming requests. It acts as middleware that checks the validity of the token provided in the request headers and decodes it for use in the application, ensuring that only valid tokens are processed.

Middleware Integration

  • jsonwebtoken:

    jsonwebtoken does not provide middleware functionality; it is a utility for creating and verifying tokens. Developers need to implement their own middleware to use this library effectively within their applications.

  • passport-jwt:

    passport-jwt is designed to work within the Passport.js framework, allowing for easy integration of JWT authentication into existing Passport strategies. It provides middleware that can be added to routes to enforce JWT authentication, making it simple to manage user sessions.

  • koa-passport:

    koa-passport integrates with Koa's middleware system, allowing for easy setup of authentication routes and flows. It can work alongside other middleware, including koa-jwt, to provide a comprehensive authentication solution tailored to the application's needs.

  • koa-jwt:

    koa-jwt is specifically designed as middleware for Koa applications. It seamlessly integrates into the Koa middleware stack, allowing developers to protect routes by simply adding it to the middleware chain, making it easy to enforce authentication across endpoints.

Flexibility and Extensibility

  • jsonwebtoken:

    jsonwebtoken is highly flexible, allowing developers to customize token payloads, expiration times, and signing algorithms. This flexibility makes it suitable for a wide range of applications that require tailored authentication solutions.

  • passport-jwt:

    passport-jwt is also extensible as part of the Passport.js ecosystem. It allows developers to combine JWT authentication with other strategies, providing a versatile solution for applications that need to support various authentication methods.

  • koa-passport:

    koa-passport is very extensible, allowing developers to add multiple authentication strategies beyond JWT. This makes it suitable for applications that may require different methods of authentication, such as OAuth or local strategies, alongside JWT.

  • koa-jwt:

    koa-jwt is focused on JWT verification and does not provide extensive customization options. Its primary purpose is to enforce authentication, making it less flexible than jsonwebtoken but straightforward to use in Koa applications.

Learning Curve

  • jsonwebtoken:

    jsonwebtoken has a relatively low learning curve, especially for developers familiar with JWT concepts. Its API is straightforward, making it easy to implement token creation and verification without extensive setup.

  • passport-jwt:

    passport-jwt is straightforward for developers who are already using Passport.js. However, understanding how to configure Passport with various strategies may require some additional learning, especially for those new to the Passport ecosystem.

  • koa-passport:

    koa-passport may have a steeper learning curve due to its integration with multiple strategies and the Passport.js framework. Developers need to understand how to configure and manage different authentication strategies effectively.

  • koa-jwt:

    koa-jwt is easy to learn for developers already familiar with Koa. Its middleware approach is intuitive, allowing for quick integration into existing Koa applications with minimal configuration.

Use Cases

  • jsonwebtoken:

    jsonwebtoken is ideal for applications that require custom token management, such as microservices or APIs where you need to generate and verify tokens independently. It is also suitable for scenarios where you want to implement your own authentication logic.

  • passport-jwt:

    passport-jwt is ideal for applications already using Passport.js for authentication. It allows developers to implement JWT authentication seamlessly alongside other strategies, providing a unified approach to user authentication.

  • koa-passport:

    koa-passport is designed for applications that require a comprehensive authentication solution with multiple strategies. It is suitable for applications that may need to support various authentication methods, including JWT, OAuth, and local authentication.

  • koa-jwt:

    koa-jwt is best suited for Koa applications that need to protect specific routes with JWT authentication. It is perfect for RESTful APIs where you want to ensure that only authenticated users can access certain resources.

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

    Choose jsonwebtoken if you need a straightforward library for creating and verifying JWTs without any additional framework dependencies. It is ideal for applications that require custom token handling and where you want full control over the token lifecycle.

  • passport-jwt:

    Use passport-jwt if you are already utilizing Passport.js for authentication in your application. This strategy allows you to authenticate users via JWTs within the Passport framework, making it suitable for applications that require a unified authentication approach with multiple strategies.

  • koa-passport:

    Opt for koa-passport if you need a comprehensive authentication solution that supports multiple strategies, including JWT. It provides a flexible way to manage user authentication in Koa applications, allowing for easy integration of various authentication methods beyond just JWT.

  • koa-jwt:

    Select koa-jwt if you are using Koa as your web framework and need a middleware solution to protect your routes with JWT authentication. This package simplifies the integration of JWTs into your Koa application, ensuring that only authenticated users can access certain endpoints.

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

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