Right now, OpenIDConnect::ResponseObject::IdToken.decode assumes public-key encryption and does not make it possible to verify a token signed with a HS256 using a shared-secret:
def decode(jwt_string, key)
if key == :self_issued
decode_self_issued jwt_string
else
new JSON::JWT.decode jwt_string, key
end
end
The problem here is that we don't actually know whether we should be passing in a the set of public keys or whether the private key is correct. If the JWT is signed with HS256, providing a set of RSA keys (via JSON::JWK::Set) will either result in:
JSON::JWK::Set::KidNotFound since no key ID is present
The caller can call JSON::JWT.decode to do this, but it seems better to put this logic in OpenIDConnect::ResponseObject::IdToken to avoid needing to do two decodings.
To fix this, we need to peek at the decoded JWT header to figure out whether to use the public or private key.
Maybe this library should provide a method to do this:
Right now,
OpenIDConnect::ResponseObject::IdToken.decode
assumes public-key encryption and does not make it possible to verify a token signed with a HS256 using a shared-secret:The problem here is that we don't actually know whether we should be passing in a the set of public keys or whether the private key is correct. If the JWT is signed with HS256, providing a set of RSA keys (via
JSON::JWK::Set
) will either result in:JSON::JWK::Set::KidNotFound
since no key ID is presentJSON::JWS::UnexpectedAlgorithm
since trying to decode a HS256 payload with a RSA key doesn't work (as mentioned in https://github.com/nov/json-jwt/issues/32#issuecomment-511084485)The caller can call
JSON::JWT.decode
to do this, but it seems better to put this logic inOpenIDConnect::ResponseObject::IdToken
to avoid needing to do two decodings.To fix this, we need to peek at the decoded JWT header to figure out whether to use the public or private key.
Maybe this library should provide a method to do this:
This touches on some of the points raised in https://github.com/nov/openid_connect/issues/42.