Expose OIDC provider server metadata in Provider

[allisonlarson]

This exposes the OIDC Provider auth server metadata that is returned during service discovery, and exposed by go-oidc, and adds a way to supply it during testing. This allows OP metadata to be accessed on the provider object once its been discovered, instead of making an additional request to the same endpoint, or having to have explicit support.

Hi! I'm an engineer on Nomad and I'm hoping to add some support for RFC 9207 (OAuth 2.0 Authorization Server Issuer Identification), which involves two steps during the OIDC Complete Authorization step of the login flow:

• Check the value of authorization_response_iss_parameter_supported of the OP auth server metadata (returned in the .well-known/openid-configuration endpoint)
• Require the iss param value in the Auth Response is present & matches based on OP support

Currently there isn't a way to check the auth server metadata via the cap/oidc library for an unsupported configuration value. Once we have a way to access the metadata, we can determine if we should manually check the iss param in the auth response. The authorization_response_iss_parameter_supported isn't required to be set, so the approach I took was to supply a way to get the configuration value out; I'm happy to discuss any other thoughts about the best way to approach. I'm hoping this will help any other users of the library support the same functionality.

The approach is to expose the same Claims() function on the Provider as defined in go-oidc, as a new function with a unit test.

The test provider has been updated to be able to supply additional server metadata that gets merged and returned in the openidConfiguration path. (The test was implemented with an arbitrary config value, but I can update it to something realistic)

PCI review checklist

• I have documented a clear reason for, and description of, the change I am making.

• If applicable, I've documented a plan to revert these changes if they require more than reverting the pull request.

• If applicable, I've documented the impact of any changes to security controls.

  Examples of changes to security controls include using new access control methods, adding or removing logging pipelines, etc.

[jimlambrt]

Suggested change

	// Claims unmarshals raw fields returned by the server during discovery.
	// Claims unmarshals raw fields returned by the provider during discovery.
	//
	// For a list of fields defined by the OpenID Connect spec see:
	// https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderMetadata
	// see also: https://datatracker.ietf.org/doc/html/rfc8414
	//
	// This list of fields may include 'authorization_response_iss_parameter_supported'
	// which can be used to prevent mix-up attacks.
	// https://datatracker.ietf.org/doc/html/rfc9207#section-3

[allisonlarson]

Thank you!

[jimlambrt]

can you add a godoc here?

[allisonlarson]

Thanks @jimlambrt! Godocs have been added & updated, ready for another pass

[jimlambrt]

Looks good! Ty.

[jimlambrt]

Ty