jsonwebtoken vs passport vs oauth vs express-session vs firebase-admin vs next-auth vs @auth0/auth0-react vs @okta/okta-sdk-nodejs vs @privy-io/server-auth
Authentication and Authorization Libraries Comparison
1 Year
jsonwebtokenpassportoauthexpress-sessionfirebase-adminnext-auth@auth0/auth0-react@okta/okta-sdk-nodejs@privy-io/server-authSimilar Packages:
What's Authentication and Authorization Libraries?

These libraries provide various solutions for implementing authentication and authorization in web applications. They cater to different needs such as user management, session handling, token generation, and integration with third-party identity providers. Understanding the unique features of each library helps developers choose the right tool for their specific use case, whether it's for a React application, a Node.js backend, or a serverless architecture.

Package Weekly Downloads Trend
Github Stars Ranking
Stat Detail
Package
Downloads
Stars
Size
Issues
Publish
License
jsonwebtoken18,452,61317,86643.5 kB171a year agoMIT
passport3,035,73423,196157 kB387a year agoMIT
oauth2,159,1092,439130 kB167-MIT
express-session2,026,8016,28886.8 kB1185 months agoMIT
firebase-admin1,917,8641,6501.34 MB19020 days agoApache-2.0
next-auth1,301,87126,095828 kB4143 months agoISC
@auth0/auth0-react508,671925870 kB33a month agoMIT
@okta/okta-sdk-nodejs102,6321036.76 MB488 months agoApache-2.0
@privy-io/server-auth24,000-724 kB-8 days agoApache-2.0
Feature Comparison: jsonwebtoken vs passport vs oauth vs express-session vs firebase-admin vs next-auth vs @auth0/auth0-react vs @okta/okta-sdk-nodejs vs @privy-io/server-auth

Integration with Identity Providers

  • jsonwebtoken:

    Does not provide direct integration with identity providers; it is used for creating and verifying tokens that can be issued by any authentication service.

  • passport:

    Supports a wide range of authentication strategies, including OAuth, OpenID, and local authentication, making it highly versatile for various applications.

  • oauth:

    Provides a framework for integrating with various OAuth providers, allowing for flexible user authentication through third-party services.

  • express-session:

    Does not integrate with identity providers directly; it is primarily used for session management within Express applications.

  • firebase-admin:

    Integrates with Firebase Authentication, allowing developers to manage users and authenticate them through Firebase's identity services.

  • next-auth:

    Offers built-in support for multiple identity providers, including OAuth and OpenID Connect, making it easy to implement authentication in Next.js applications.

  • @auth0/auth0-react:

    This package provides seamless integration with Auth0, allowing developers to easily authenticate users via various identity providers such as Google, Facebook, and enterprise SSO solutions.

  • @okta/okta-sdk-nodejs:

    Okta's SDK offers robust integration with Okta's identity services, enabling user authentication and management through a centralized identity provider.

  • @privy-io/server-auth:

    This package focuses on privacy-centric authentication, allowing integration with various identity providers while ensuring compliance with data protection regulations.

Session Management

  • jsonwebtoken:

    Does not manage sessions directly; it is used for token-based authentication, where the token can be stored in client-side storage for session management.

  • passport:

    Provides session management capabilities through Express, allowing for persistent login sessions and user state management.

  • oauth:

    Does not manage sessions directly; it focuses on the authorization process and token handling for third-party services.

  • express-session:

    Provides a straightforward way to manage sessions in Express applications, allowing developers to store session data on the server and maintain user state across requests.

  • firebase-admin:

    Manages user sessions through Firebase Authentication, leveraging Firebase's infrastructure for secure session handling.

  • next-auth:

    Offers built-in session management capabilities, allowing developers to manage user sessions easily in Next.js applications.

  • @auth0/auth0-react:

    Handles user sessions automatically through Auth0's management, simplifying the process of maintaining user state in React applications.

  • @okta/okta-sdk-nodejs:

    Provides session management features through Okta's platform, allowing for secure handling of user sessions in Node.js applications.

  • @privy-io/server-auth:

    Focuses on secure session management with a strong emphasis on privacy and compliance, suitable for applications with strict data handling requirements.

Security Features

  • jsonwebtoken:

    Offers security features through token signing and verification, ensuring that tokens are tamper-proof and securely transmitted between client and server.

  • passport:

    Provides security features through various authentication strategies, ensuring that user credentials are securely handled and verified.

  • oauth:

    Focuses on secure authorization flows, ensuring that access tokens are securely managed and transmitted, but does not handle user authentication directly.

  • express-session:

    Provides basic security features such as session expiration and cookie management, but relies on additional middleware for enhanced security.

  • firebase-admin:

    Includes security features such as user authentication verification, role-based access control, and secure token management through Firebase services.

  • next-auth:

    Includes security features such as session expiration, CSRF protection, and secure handling of authentication tokens, making it suitable for modern web applications.

  • @auth0/auth0-react:

    Offers built-in security features such as token expiration, refresh tokens, and secure storage of user credentials, ensuring a secure authentication process.

  • @okta/okta-sdk-nodejs:

    Includes advanced security features like multi-factor authentication (MFA), adaptive authentication, and secure token management to enhance user security.

  • @privy-io/server-auth:

    Focuses on privacy and security, ensuring that user data is handled according to strict compliance standards, making it suitable for sensitive applications.

Ease of Use

  • jsonwebtoken:

    Simple to use for creating and verifying tokens, but requires understanding of token-based authentication concepts.

  • passport:

    Offers a flexible and modular approach to authentication, but may have a steeper learning curve due to the variety of strategies available.

  • oauth:

    Can be complex to implement due to the various flows and providers, but offers flexibility for those familiar with OAuth standards.

  • express-session:

    Extremely easy to use within Express applications, providing a simple API for session management without complex setup.

  • firebase-admin:

    Offers a straightforward API for managing users and authentication, especially for developers already familiar with Firebase services.

  • next-auth:

    Provides a simple and intuitive API for Next.js applications, making it easy to implement various authentication strategies with minimal configuration.

  • @auth0/auth0-react:

    Designed specifically for React applications, it offers a simple API and clear documentation, making it easy for developers to implement authentication.

  • @okta/okta-sdk-nodejs:

    Provides a well-structured SDK with comprehensive documentation, making it straightforward to integrate Okta's identity services into Node.js applications.

  • @privy-io/server-auth:

    Offers a user-friendly API focused on privacy, but may require additional configuration for specific use cases.

Community and Support

  • jsonwebtoken:

    A popular package with a large user base, it has extensive documentation and community support available for token-based authentication.

  • passport:

    Well-established in the Node.js community, it has extensive documentation and a wide range of strategies available, ensuring strong community support.

  • oauth:

    Standardized protocol with a large community, but specific implementations may vary in support and documentation quality.

  • express-session:

    Widely used in the Express community, it has extensive documentation and community support available across various forums.

  • firebase-admin:

    Part of the Firebase ecosystem, it has a large community and extensive resources available for developers using Firebase services.

  • next-auth:

    Growing community support with extensive documentation and examples, making it easier for developers to implement authentication in Next.js applications.

  • @auth0/auth0-react:

    Backed by Auth0, it has a strong community and extensive support resources, including documentation and tutorials.

  • @okta/okta-sdk-nodejs:

    Supported by Okta, it has a robust community and provides comprehensive documentation and support resources for developers.

  • @privy-io/server-auth:

    A smaller community focused on privacy, but offers dedicated support for users concerned with data handling and compliance.

How to Choose: jsonwebtoken vs passport vs oauth vs express-session vs firebase-admin vs next-auth vs @auth0/auth0-react vs @okta/okta-sdk-nodejs vs @privy-io/server-auth
  • jsonwebtoken:

    Select this package if you need to create and verify JSON Web Tokens (JWT) for authentication. It is lightweight and can be easily integrated into any Node.js application for secure token-based authentication.

  • passport:

    Select this package if you need a comprehensive authentication middleware for Node.js. It supports a wide range of authentication strategies and can be easily integrated into Express applications.

  • oauth:

    Choose this package if you need to implement OAuth 2.0 authorization flows in your application. It provides a standard way to authenticate users via third-party services and manage access tokens securely.

  • express-session:

    Use this package if you need to manage user sessions in an Express.js application. It provides a simple way to store session data on the server, allowing you to maintain user state across requests without relying on client-side storage.

  • firebase-admin:

    Choose this package if you are developing applications that leverage Firebase services. It allows you to manage users, authenticate them, and access Firebase features like Firestore and Cloud Functions, making it a great choice for serverless applications.

  • next-auth:

    Use this package if you are building a Next.js application and require a flexible authentication solution. It supports various authentication providers and allows for easy integration with databases and session management.

  • @auth0/auth0-react:

    Choose this package if you are building a React application and want to integrate Auth0 for authentication. It provides a simple way to manage user sessions, handle authentication flows, and access user information directly within your React components.

  • @okta/okta-sdk-nodejs:

    Select this package if you need a comprehensive identity management solution for Node.js applications. It offers features for user authentication, user management, and integration with Okta's identity platform, making it ideal for enterprise-level applications.

  • @privy-io/server-auth:

    Opt for this package if you are looking for a server-side authentication solution that focuses on privacy and security. It is suitable for applications that require strict data handling policies and compliance with privacy regulations.

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.