feat: configure client assertion issuer

[tilgovi]

Allow clients to have a custom client assertion issuer so that a client assertion can be issued by a separate identity provider rather than only self-issued.

BREAKING CHANGES: The Client interface defines a new method to return the issuer expected in client assertions. Applications that define their own type must implement Client.GetJSONWebTokenClientAssertionIssuer.

Related Issue or Design Document

Checklist

• I have read the contributing guidelines and signed the CLA.
• I have referenced an issue containing the design document if my change introduces a new feature.
• 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 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 the necessary documentation within the code base (if appropriate).

Further comments

[tilgovi]

I did not open a separate issue with a design document because the change being proposed here seems small enough that it might not make sense.

The idea here is that RFC 7521 Section 6.1 suggests that assertions for client authentication do not need to be self-issued:

The Subject of the assertion identifies the client. If the assertion is self-issued by the client, the Issuer of the assertion also identifies the client.

The use of "if" in the second sentence quoted above suggests that the issuer does not need to identify the client if the assertion is not self-issued.

Hydra requires that client assertions have the client_id in the iss claim, but this feature removes that requirement, enabling Hydra (or other applications) to allow customization of the issue for each client. This feature helps with federation scenarios where another issuer exists already. This scenario is achievable with Hydra today by using JWT authorization grants, but requires managing the trust relationship separately from the client and requires clients to specify the Client ID in a request parameter. Using a client assertion more accurately captures the intent for the client to obtain authorization to act as itself.

[tilgovi]

I'm very open to any feedback at all as this is my first fosite contribution.

[tilgovi]

I see that there are tests that are failing because they try to build Hydra against this branch. I have a working Hydra branch, but it doesn't have any tests yet.

[tilgovi]

Here is the Hydra branch in progress.