fix: include client_assertion in token hook payload

[phooijenga]

We want to use JWTs for client authentication in combination with a token hook.

Related issue(s)

When a client authenticates via the private_key_jwt auth method the payload includes

client_assertion_type=urn:ietf:params:oauth:client-assertion-type:jwt-bearer

and

client_assertion=<signed-jwt>

This works, and the token hook is called, but it does not include the assertion.

Checklist

• I have read the contributing guidelines.
• I have referenced an issue containing the design document if my change
  introduces a new feature.
• I am following the
  contributing code guidelines.
• I have read the security policy.
• I confirm that this pull request does not address a security
  vulnerability. If this pull request addresses a security vulnerability, I
  confirm that I got the approval (please contact
  security@ory.sh) from the maintainers to push
  the changes.
• I have added tests that prove my fix is effective or that my feature
  works.
• I have added or changed the documentation.

Further Comments

I didn't see any tests for the private_key_jwt auth method, so I copied and modified some of the existing tests for JWT as Authorization Grant.

[aeneasr]

That‘s on purpose - like we don’t include the client_secret, auth code, or other tokens.

[phooijenga]

`client_assertion` is not a secret though, and `assertion` _is_ included.

…

On Thu, Feb 20, 2025, 17:36 hackerman ***@***.***> wrote: That‘s on purpose - like we don’t include the client_secret, auth code, or other tokens. — Reply to this email directly, view it on GitHub <#3949 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BAGBHIQBEFRH423MQHI6LSD2QYAA7AVCNFSM6AAAAABXQHT2XCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZSGAZTSNBRGI> . You are receiving this because you authored the thread.Message ID: ***@***.***> [image: aeneasr]*aeneasr* left a comment (ory/hydra#3949) <#3949 (comment)> That‘s on purpose - like we don’t include the client_secret, auth code, or other tokens. — Reply to this email directly, view it on GitHub <#3949 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BAGBHIQBEFRH423MQHI6LSD2QYAA7AVCNFSM6AAAAABXQHT2XCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMNZSGAZTSNBRGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[aeneasr]

Would it not be possible to replay the auth grant with the assertion?

[phooijenga]

A replay attempt would be rejected because the jti was already used; which is required for this flow.

[aeneasr]

I see, it will probably more difficult to implement, but what do you think of instead including the client assertion claims and not the token itself, so that the webhook target does not need to verify the JWT?

[phooijenga]

Yeah, that would work; I'll see if I can figure out how to do that.

[phooijenga]

Getting the claims also requires some changes in Fosite, for which I have created ory/fosite#844. I based it on v0.49.0 to avoid adding unnecessary changes in this MR, which now has a replace in the go.mod to demonstrate the tests passing.

I'm not sure the approach I took to make the claims available is the right one, and it should probably have a test.

[mitar]

I am curious, why do you need access to the assertion itself/claims in the hook?

[phooijenga]

We want to validate/verify some of the claims in the assertion, and copy them to the access token.

[mitar]

But isn't everything in the assertion self-asserted? Client can put anything they want in there?

[phooijenga]

Yes, we are aware :)

[aeneasr]

That's quite dangerous, I would say! Access tokens should only have trusted content

[mitar]

Maybe they have some out-of-band way of verifying content, like additional signatures and stuff. Or maybe it is non-critical stuff like first and last name they allow one just to pick arbitrary.