Closed mikekellyio closed 1 year ago
Your ID Tokens are not encrypted, you're setting encryption related properties though.
I started to write an angry reply about how it was the open-id library calling this code so the problem had to be there somewhere, but in the process of staring harder at the openid-client
code to find my evidence I fixed my problem.
Leaving this in case someone else goes down this trail.
If I leave my client config without setting the alg, I get a different error.
// Client configuration (client.metadata) and how it is constructed (fromUri or manual?)
{
client_id: <id>,
client_secret: <secret>,
response_types: ["code"]
}
results in: RPError: Unexpected JWT alg received, expected RS256, not RS512
in Client.validateJWT client.js:890.
My ultimate problem was that when reading the docs trying to figure out what config options to get past the above error, I chose the encrypted response ones rather than the signed response. Once I used id_token_signed_response_alg: "RS512"
in my config, life got much better.
Describe the bug
When a Id Token with a JWE Header (below) is passed into
decryptJWE
, an error is thrown:RPError: unexpected JWE enc received, expected A128CBC-HS256, got: undefined
To Reproduce Issuer and Client configuration: (inline or gist) - Don't forget to redact your secrets.
It appears that since there is a default value for
expectedEnc
, ifheader.enc
is undefined an error will always be thrown. I am unable to find documentation in the RFC's suggesting thatheader.enc
should be required, and I am running into this issue when integrating with PingFederate.Steps to reproduce the behaviour:
decryptJWE
Expected behaviour No error is thrown.
Environment:
Additional context Add any other context about the problem here.