RFC confrontation on "none" algo

[frankli0324]

Description

According to https://tools.ietf.org/html/rfc7518#section-3.6, jws s "MUST NOT accept such objects as valid unless the application specifies that it is acceptable for a specific object to not be integrity protected"

Reproduction

> var token = jwt.sign({'a':1}, 'asdf', { algorithm: 'none'})
undefined
> jwt.verify(token)
{ a: 1, iat: 1587359376 }

maybe we should add some kind of switch options?

Expected output:

> var token = jwt.sign({'a':1}, 'asdf', { algorithm: 'none'})
undefined
> jwt.verify(token)
throws error
> jwt.verify(token, '', { algorithm: 'none'})
{ a: 1, iat: 1587359376 }

[frankli0324]

node-jsonwebtoken/verify.js

Lines 109 to 111 in 5f10bf9

	if (!hasSignature && !options.algorithms) {
	options.algorithms = ['none'];
	}

so it's intentional?

[panva]

@frankli0324 none won't be automatically accepted unless the developer provided no keyOrSecret. The three lines in isolation aren't the whole story.

node-jsonwebtoken/verify.js

Lines 101 to 118 in 5f10bf9

	if (!hasSignature && secretOrPublicKey){
	return done(new JsonWebTokenError('jwt signature is required'));
	}
	if (hasSignature && !secretOrPublicKey) {
	return done(new JsonWebTokenError('secret or public key must be provided'));
	}
	if (!hasSignature && !options.algorithms) {
	options.algorithms = ['none'];
	}
	if (!options.algorithms) {
	options.algorithms = secretOrPublicKey.toString().includes('BEGIN CERTIFICATE') ||
	secretOrPublicKey.toString().includes('BEGIN PUBLIC KEY') ? PUB_KEY_ALGS :
	secretOrPublicKey.toString().includes('BEGIN RSA PUBLIC KEY') ? RSA_KEY_ALGS : HS_ALGS;
	}

[frankli0324]

from my point of view, providing no secret doesn't mean that one explicitly "specifies that it is acceptable for a specific object to not be integrity protected", more like a mistake one could jump into

[panva]

We'll consider making the algorithms option required when accepting unsigned JWTs for the next major.

[frankli0324]

seems that this issue is forgotten?

[jakelacey2012]

This issue was fixed in #851, please do re-open if you have any questions.