Revisit internal config adjustment behavior for OIDC discovery

[ayoho]

Liberty does some internal adjustments to the OIDC client config based on what the OP supports per its discovery document. For example, if the client has HS256 configured but the OP only supports RS256, we’ll internally switch the OIDC client config to use RS256. In the case that an OP's discovery endpoint does not have an entry for token_endpoint_auth_signing_alg_values_supported, Liberty is internally switching the client to set that value to null instead of the default of RS256. That can cause the OIDC client to fail to create a JWT for the private_key_jwt client authentication type because it skips setting the "alg" header in the JWT.

We should revisit this logic for internally switching config values, particularly related to the private_key_jwt functionality, but also for config in general.

[barbj]

@ayoho I think that this might be the issue:

Social calls this method in DiscoveryConfigUtils , but OidcClientConfigImpl never does. public DiscoveryConfigUtils discoveredConfig(String alg, String tokenepAuthMethod, String tokenEndpointAuthSigningAlgorithm, String scope) {

Because of this, DiscoveryConfigUtils never picks up the default (or configured) value that OidcClientConfigImpl picked up for tokenEndpointAuthSigningAlgorithm earlier in the process. DiscoveryConfigUtils is always left with its class variable tokenEndpointAuthSigningAlgorithm set to null.

Therefore, adjustTokenEndpointAuthSigningAlgorithm will always return null when there is no token_endpoint_auth_signing_alg_values_supported in the discovery output.