First of all - thanks for the great gem!
What I've stumbled upon while using the gem is the verification of additional attributes, like e.g. the "iss" claim. When "iss" is supplied to the options in JWT.decode it is not enforced or checked, even when verify_iss is set to true as long as it's not present in the actual payload. Basically I've had the following decoding code:
options = {
algorithm: 'HS256',
verify_iss: true,
'iss' => 'acme.org'
}
payload, = JWT.decode(token, "secret", true, options)
and provided it a token like:
token = JWT.encode({ data: 'payload' }, 'secret', 'HS256')
and expected it to raise an error, because iss is not set in the payload - is this assumption wrong? Should the presence of these attributes be verified again by the application? Looking at jwt.rb#166 the issuer is only verified when it's present in the payload. From my point of view - and I think the more "safe" variant - would be to always trust the options and when "iss" is present in the options then enforcing the check against the issuer.
PS: I'm not savvy with the JWT spec, so it can be that the JWT spec actually proposes the current design. Then just ignore & close my issue :)
PPS: And if this proposal makes sense, I'd be happy to create a PR
First of all - thanks for the great gem!
What I've stumbled upon while using the gem is the verification of additional attributes, like e.g. the
"iss"claim. When"iss"is supplied to the options inJWT.decodeit is not enforced or checked, even whenverify_issis set to true as long as it's not present in the actual payload. Basically I've had the following decoding code:and provided it a token like:
and expected it to raise an error, because
issis not set in the payload - is this assumption wrong? Should the presence of these attributes be verified again by the application? Looking at jwt.rb#166 the issuer is only verified when it's present in the payload. From my point of view - and I think the more "safe" variant - would be to always trust theoptionsand when"iss"is present in the options then enforcing the check against the issuer.PS: I'm not savvy with the JWT spec, so it can be that the JWT spec actually proposes the current design. Then just ignore & close my issue :)
PPS: And if this proposal makes sense, I'd be happy to create a PR