Metadata ownership & Logout

[fabianfreyer]

When creating a Client, Client::from_metadata takes ownership of the provider metadata.

Why is this a problem?

I ran into this when implementing logout. I need a way to retrieve the logout endpoint from a ProviderMetadataWithLogout, but couldn't find a way to keep the metadata around after creating the client or cloning the metadata. Keeping cloned Metadata around feels unnecessarily ugly, and in places where I have access to a Client, I would also expect to not need an additional state variable to keep the metadata.

Possible Solutions

• None of the methods it calls on require this, it should therefore be fine to have Client::from_metadata take a &ProviderMetadata<...>. This would be a breaking change.
• The metadata could be saved completely on a field of the Client, and a method exposed to retrieve them. However, this would mean that the Generic templates of ClientMetadata would need to be moved to Client as well, so this would be a breaking change as well.
• Have Client::from_metadata retrieve the logout endpoint and optionally save it on the Client when available.
• Ideally, have a Client that is created from ProviderMetadataWithLogout implement an end_session method that crafts the correct EndSessionRequest.

Workarounds

• Users Clone the metadata before passing it to Client::from_metadata.
• Users read any metadata fields they need from the ProviderMetadata and take care of storing them elsewhere.

[ramosbugs]

The purpose of the Client is to provide APIs for certain OIDC functionality. It's not to be a carrier of ProviderMetadata, and in fact provider metadata isn't even required to instantiate a Client. If other fields from provider metadata are useful to applications, then it makes sense that they should keep track of those separately.

If we were to change the from_metadata API to take a reference, that would just mean that the Client would have to clone the fields it needs internally, which introduces a breaking change affecting most users of this crate without a clear benefit. To avoid cloning, we would have to introduce a generic lifetime into Client, which would cause endless headaches for users. I think the current API strikes the optimal balance for most use cases.