well-known URLs not accessible from `Provider`

[tfahrenreich]

It would be helpful to be able to call ProviderConfig() on Provider to return a reusable config, or make the fields not private

I'm working on a project that requires caching the OpenID discovery request.

From Provider I'm trying to extract the fields needed to create a ProviderConfig which I can then cache and recall using ProviderConfig.NewProvider

Is there a reason to keep fields on Provider private? Some are available through UserInfoEndpoint and Endpoint. These aren't sensitive URLs since they're publicly available through discovery.

Please let me know if there's another method for retrieving these fields that I might be missing. Thanks!

[ericchiang]

Would you mind showing an example of what you're trying to do? Are you trying to serialize the state of a Provider instance?

[amir4895]

@ericchiang I think he want to reuse and not fetching each time, having the same scenario , azure legging in response once in a while and I prefer to cache but deosnt seems that the functionality exists

[YoSev]

I have the same request. Discord's openid-configuration doesn't hold a userinfo_endpoint even tho it is supported (and required).

A helper method to set the UserInfoURL manually would already help.

[mcarbonneaux]

in Provider EndPoint you have access to TokenURL and AuthURL after discovery but not the other (like UserInfoURL).
you can print provider object and you see UserInfoURL and JWKURL too.

	provider, err := oidc.NewProvider(ctx, issuerUrl)
	if err != nil {
		log.Fatal(err)
	}

	fmt.Println("issuer discovery:", provider)  // print all discovered information, including userinfo url
	fmt.Println("TokenURL:", provider.Endpoint().TokenURL) // print Token url
	fmt.Println("Token AuthURL:", provider.Endpoint().AuthURL) // print auth url

[mathewTH]

I agree this would be useful. In my situation I want to use a custom KeySet (very similar to RemoteKeySet but working around issues I'm having with that one, I will raise a separate issue for that). The unavailability of the jwks url means I would need to do a separate well-known request.