Options hash uses both symbols and strings as keys.

[aj-michael]

I tried to verify the issuer on a JWT that I was decoding today, and I found this line (and others like it) very ugly.

if options[:verify_iss] && options['iss']

This means that my code to decode the JWT looked like this:

JWT.decode(token, public_key, true, :verify_iss => true, 'iss' => 'my issuer')

In my opinion, the consumer of this API should be be able to do one of the following:

1. Always use symbols as keys in the options hash.
2. Always use strings as keys in the options hash.
3. Be able to either use symbols or keys in the options in hash and have our library deal with it under the hood.

Thoughts?

[yordis]

👍 for symbol only until someone complain about it 😄

[excpt]

👍 symbols only :)

[skippy]

+1

This is an issue beyond semantics... @aj-michael it is a security hole.

I pass in the following:
{:aud=>"test_aud_id", :verify_aud=>true}

and it decodes the token successfully. The hole is it decodes regardless of what the aud is. You can see this bug in line jwt.rb#172 if options[:verify_aud] && options['aud']

if I pass in:
{:aud=>"test_aud_id", :verify_aud=>true, :verify_iat=>true, :sub=>"test_sub_id", :verify_sub=>true}

this fails because how the verify_sub checks, it doesn't allow it to silently fail (even though sub is set in the token)

[excpt]

@aj-michael @yordis @skippy :)

[skippy]

@excpt fair enough! I wasn't trying to be snarky. Thank you for the fast PR!

[yordis]

@excpt awesome, very good clean there 👍