Closed gtorresani closed 3 years ago
However the client_secret is currently base64url encoded.
client_secret values are not base64url encoded, they are the actual utf-8 octets to use. The behaviour exhibited by openid-client is correct and has been confirmed with the openid foundation conformance software as well as years of actual usage against a number of identity providers.
Only when representing a client_secret as an oct
JWK needs the value of the client_secret be additionally base64url encoded, that comes from the JWK specification.
Thank you for your quick response
Indeed I find the results of the tests however no test is carried out with the HS256 algorithm, only the RS256 algorithm is tested during the certification.
Otherwise why the JWT in the example of RFC 7515 does not work by performing a base64UrlEncode of client_secret while it works without base64UrlEncode.
I'm not sure how to properly decode your answer and the issue, there's a lot mixup in there, so let's try differently.
What is the client_secret
value given to you by your IdP? (generate a new client for this, don't post your actual one).
The secret value in the JWK you posted is not a valid client_secret value, it containts invalid char codes. That's why you can't pass just the base64url decoded string value of the "k" property as the secret, because no idp will give you such value as a client_secret
Currently, the joseSecret function creates a JWK based on the base64UrlEncode representation of client_secrete, while the OpenId-Connect standard requires that it be the octets of the UTF-8 representation of client_secret. Otherwise it is not necessary to perform a base64url encoding.
The function returns an oct
JWK representation of the client_secret. In which the octets of a string will be base64url encoded otherwise it's not encoded as a JWK properly, the underlying crypto will decode the k
again to end up with a non-encoded secret. Passing in just the string would yield exactly the same results.
Thanks for those details.
So if my client_secret is aBCD1234,;:-=
the associated OctKey is
{
"kid": "cWzWbpYC9nKIbXmQMXk2CHfjdu28DENLjLjS-fk93gc",
"kty": "oct",
"k": "YUJDRDEyMzQsOzotPQ"
}
In this case everything works to decode the JWT eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJqb2UiLCJleHAiOjEzMDA4MTkzODAsImh0dHA6Ly9leGFtcGxlLmNvbS9pc19yb290Ijp0cnVlfQ.BOy50CByAmMGzdDnG_vsRm7BuF5uvdKycTc0zVWzHxA
Thank you for your responsiveness and sorry for my unnecessary request.
You got it.
Please consider supporting the library if it provides value to you or your company and this support was of help to you. Supporting the library means, amongst other things, that such support will be available in the future.
Describe the bug
When using the HS256 algorithm to sign the JWT according to the specifics of OpenId-Connect, the signing key must be the octets of the UTF-8 representation of client_secret. However the client_secret is currently base64url encoded.
https://openid.net/specs/openid-connect-core-1_0-13.html#IDTokenValidation
To Reproduce I have used the example provided in RFC 7515, JWS Using HMAC SHA-256.
OctKey
JWT
Current behavior results
Currently, the joseSecret function creates a JWK based on the base64UrlEncode representation of client_secrete, while the OpenId-Connect standard requires that it be the octets of the UTF-8 representation of client_secret. Otherwise it is not necessary to perform a base64url encoding.
Expected behaviour
Environment:
Additional context