HS256 signature fails validation using python-jose

[erhhung]

Summary

I'm using jwt-cli to generate a JWT using the default HS256 algorithm, but the token is failing validation using the python-jose module. I'm not sure whether it's the way I'm using the --secret parameter, or the relationship between the --secret value and the JWK's "k" value, or a bug in either code base.

Steps to reproduce

$ token=$(jwt encode --iss self --sub foo --exp "+1Y" --secret secret)

# eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2NTM3MTMxMTgsImlhdCI6MTYyMjE1NjE2NiwiaXNzIjoic2VsZiIsInN1YiI6ImZvbyJ9.fAMgjQScd7xsfOV0-3XvD5K3P7Toc1zLS1ECoeNTEPg

$ jwt decode "$token" --secret secret

Token header
------------
{
  "typ": "JWT",
  "alg": "HS256"
}

Token claims
------------
{
  "exp": 1653713118,
  "iat": 1622156166,
  "iss": "self",
  "sub": "foo"
}

In Python REPL using python-jose following the JWK example:

# Python 3.9.5 (default, May  4 2021, 03:33:11)
# [Clang 12.0.0 (clang-1200.0.32.29)] on darwin
# python-jose==3.2.0

>>> from jose import jwk
>>> from jose.utils import base64url_decode, base64url_encode

>>> token = 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2NTM3MTMxMTgsImlhdCI6MTYyMjE1NjE2NiwiaXNzIjoic2VsZiIsInN1YiI6ImZvbyJ9.fAMgjQScd7xsfOV0-3XvD5K3P7Toc1zLS1ECoeNTEPg'

>>> message, encoded_sig = token.rsplit('.', 1)
# message = 'eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJleHAiOjE2NTM3MTMxMTgsImlhdCI6MTYyMjE1NjE2NiwiaXNzIjoic2VsZiIsInN1YiI6ImZvbyJ9'
# encoded_sig = 'fAMgjQScd7xsfOV0-3XvD5K3P7Toc1zLS1ECoeNTEPg'

>>> hmac_key = {'alg':'HS256', 'kty':'oct', 'k':'secret'}
>>> key = jwk.construct(hmac_key)

>>> decoded_sig = base64url_decode(encoded_sig.encode())
>>> key.verify(message.encode(), decoded_sig)
# NOT WHAT I EXPECTED!
False

>>> base64url_encode(key.sign(message.encode())).decode()
# jwt-cli produced "fAMgjQScd7xsfOV0-3XvD5K3P7Toc1zLS1ECoeNTEPg"
'6QZYk7mXWP2_Tvoubc1fAytPWfx08UHPaOJZrMWLUdI'

Expected behavior

JWT produced by jwt-cli can be validated by python-jose.

Environment & version

OS: macOS 10.15.7
jwt-cli: 4.0.0

[erhhung]

I found the error in my example and usage, and there's no issue with jwt-cli.

I had not realized that the JWK's "k" value must be base64-encoded.

>>> k = base64url_encode(b'secret').decode()
# k = 'c2VjcmV0'
>>> hmac_key = {'alg':'HS256', 'kty':'oct', 'k':k}
>>> key = jwk.construct(hmac_key)

>>> key.verify(message.encode(), decoded_sig)
True

In my actual use case, I used https://github.com/latchset/jose to create a JWKS, and then created the JWT using jwt-cli since jose, curiously, didn't have a command to create JWT. I had directly used that "k" value as the --secret value.

$ jose jwk gen -s -i '{"alg":"HS256"}'

{"keys":[{"alg":"HS256","k":"iX0BTw7_BWJ1C5dwR0yGmNDG-GTf44AsUaq4QttnbxU","key_ops":["sign","verify"],"kty":"oct"}]}

This means I'd have to decode the base64-encoded random bytes to use as --secret, but jwt-cli chokes on binary input:

$ jwt encode --iss self --sub foo --exp "+1Y" \
    --secret "$(base64 -d <<< "iX0BTw7_BWJ1C5dwR0yGmNDG-GTf44AsUaq4QttnbxU")"

thread 'main' panicked at 'unexpected invalid UTF-8 code point', /Users/runner/.cargo/registry/src/github.com-1ecc6299db9ec823/clap-2.33.3/src/args/arg_matches.rs:118:40
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace

[mike-engel]

Closing in favor of generic JWKS support in #129