Version 9.0.1 fails with a number of errors when { algorithms: ['none'] } is passed

[rachellerathbone]

I'm migrating from version 8 to 9. According to your migration docs, to migration from 8 > 9 I only need to:

• ensure I'm running on a version of Node 12 or higher (using version 16.19.1)
• pass { algorithms: ['none'] } to the verify function for unsigned tokens.

However, there seems to be a number of failure points in 9.0.x:

1. Line Adds .verify option maxAge #110 - secretOrPrivateKey != null && !(secretOrPrivateKey instanceof KeyObject - in verify.js
   The type for secretOrPrivateKey is Secret which is any of the following:

export type Secret =
    | string
    | Buffer
    | { key: string | Buffer; passphrase: string };

You can't call instance of on anything except an object otherwise you end up with TypeError: Right-hand side of 'instanceof' is not an object. This could be easily resolved by wrapping the conditional block where this call is made in an additional check e.g. typeof secretOrPublicKey === "object

Unfortunately, there are more failure points beyond this.

2. Lines Order of JSON key, value pairs  #148-150 in verify js

if (options.algorithms.indexOf(decodedToken.header.alg) === -1) {
      return done(new JsonWebTokenError('invalid algorithm'));
    }

Despite your migration docs stating you can simply pass 'none' to the algorithms array, the value of decodedToken.header.alg is HS256 (HMAC using SHA-256 hash algorithm). So obviously, when you pass { algorithms: ['none'] } this fails this check and spits out the error invalid algorithm. Even if this conditional is updated to check if 'none' is being passed to algorithms, it then fails on line #152 if (header.alg.startsWith('HS') && secretOrPublicKey.type !== 'secret') because header.alg is HS256. Then, if you resolve this error, the next one you hit is invalid signature because verify, set on line #169 valid = jws.verify(jwtString, decodedToken.header.alg, secretOrPublicKey); returns false (again because decodedToken.header.alg is defaulting to the default value and not honouring 'none'). However, if you add another conditional check to bypass the validation conditional if 'none' is passed, it succeeds without any errors.

Can someone look at updating this? Or, if this is actually the intended behaviour, update the migration docs to reflect this as passing 'none' clearly isn't supported with the current implementation.