feat: pass associated oauth client data to token hook

[terev]

Enables passing a sanitized copy of the associated oauth client to token hooks. I left the ClientID parameter as is to avoid this being a breaking change.

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
  [email protected]) 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.

[aeneasr]

Awesome, thank you for your contribution! This looks pretty good and I have some ideas how to improve it further :)

[aeneasr]

This is a fundamentally different approach to forwarding request data:

• Before: We restrict the list of parameters to a set of known values that don't leak sensitive data
• Now: We try to guesstimate a list of parameters we better not include but can not guarantee that all requirements are met

I'm really not sure if I agree with this approach. I would rather extend the default allowed parameters to include all known parameters that are OK to forward like prompt etc.

The problem with the parameters is that it includes data from the POST payload which is quite likely to contain sensitive things like tokens, passwords, assertions, signatures, ...

[terev]

@aeneasr

Thanks for having a look, really appreciate your team's work! My goal is to pass any additional and non sensitive parameters to the token hook. I was unable to find any guidelines around transmission of additional token endpoint parameters other than that they have to be stored. So I figured this meant they might be fine to utilize in an extensible manner.

For my approach, my thinking was that the set of sensitive parameters for a given token request is actually constrained based on the grant types requested. So its easy to determine this set and filter them out. Is there additional sensitive parameters I didn't include? For what its worth assertion is already specifically leaked to token hooks.

A couple other approaches i considered:

• Always filter all sensitive parameters out but I opted to generate the set based on grant type so there's a clean signal of test failure if a new grant type is added but not supported by this function.
• Make the list of acceptable additional parameters configurable in the token_hook (with validation to exclude any oauth params).

[terev]

@aeneasr I've reduced the scope of this mr to just passing the oauth client to the token hook, as it seems like the extra parameters part of the original motivation was controversial. I would still be very interested to hear your thoughts on this if you have any.