Passport.js local and JWT strategies: verify callback argument consistency

Answer to the core question

Passport.js does not enforce a fixed number of arguments for the done callback that a strategy’s verify function must invoke. In practice, the callback is called with either two arguments (err, user) or three arguments (err, user, info). Both passport-local and passport-jwt accept the third info argument, but most examples call done with only two arguments when no additional information is needed.

Why the difference matters

Strategies differ in the parameters they pass to verify:

• passport-local – (username, password, done)
• passport-jwt – (jwt_payload, done)

Regardless of those input parameters, the done callback that you invoke inside verify follows the same contract: done(err, user, info?). If you omit info, Passport simply receives undefined for that slot.

Practical recommendation for cross‑strategy compatibility

1. Always call done with three arguments: done(null, user, null) when you have no info to return. This guarantees that the info slot is defined for every strategy.
2. When you do have additional data, pass it as the third argument: done(null, user, {role: 'admin'}).
3. In your authentication middleware (e.g., passport.authenticate()), treat info as optional: function(req, res, next) { /* info may be undefined */ }.
4. If you prefer a single verify implementation, keep its signature generic: function verify(...args) { const done = args.pop(); /* args[0] and args[1] are strategy‑specific */ done(null, user, null); }.

By always supplying the third argument, you avoid conditional logic that checks arguments.length in downstream code. The Passport core and the community libraries treat a missing info the same as undefined, so the explicit null value is harmless and fully compatible.

When to double‑check the strategy’s source

Some older or custom strategies may not construct the info object at all, even when you pass it. Inspect the strategy’s verify implementation or its README to confirm whether it ever populates info. If you find a strategy that never uses the third argument, the explicit null call above remains safe.

Missing diagnostic detail?

If your application uses a third‑party strategy that you suspect might behave differently, let us know the strategy name and version. That way we can confirm whether it expects a three‑argument done call or not.