[keycloak-dev] OIDC Discovery-enabled IdentityProvider

All-- After observing that the Google Social Identity Provider in Keycloak was using a deprecated userprofile endpoint [ <https://issues.jboss.org/projects/KEYCLOAK/issues/KEYCLOAK-9179> Keycloak-9179, <https://issues.jboss.org/browse/KEYCLOAK-9169> Keycloak-9169], I wanted to propose the creation of an IdentityProvider that will use the OIDC Discovery mechanism to dynamically build a config [ <https://issues.jboss.org/browse/KEYCLOAK-9194> Keycloak-9194]. I see a few decision points along the way that I wanted to ask about before an implementation, since I'm very new to keycloak and just starting to understand the codebase. In particular, I wondered if this group could share insight into these couple issues so I can make a more informed design: 1. It looks to me like the actual IdentityProviders are instantiated just as they're being used, but that the models are persisted in the RealmModel. It's not clear to me where the separation of concerns is supposed to be between the IdentityProvider and the IdentityProviderModel-in particular since the GoogeIdentityProvider, say, immediately sets endpoints in its constructor. Normatively, where *should* social identity providers' model configuration be set (and, e.g., where are the models first added to the RealmModel)? 2. I see that there is logic to parse OIDC Discovery configuration as part of configuring Keycloak itself as an OIDC provider / implementer of OIDC protocol (including building and parsing the .well-known config elements), but that logic seems not to be used in any setting currently as a client. Should I plan to reuse, say, the OIDCConfigurationRepresentation and OIDCWellKnownProvider classes for their logic in handling such configs? Currently, I'm imagining something along the lines of extending OIDCIdentityProvider with a new OIDCDiscoveryIdentityProvider that adds a discoverConfig method which can be used by an implementing class (such as GoogleIdentityProvider) to discover and cache endpoints such that they are not hard-coded into the implementing class. Each implementing class would then have a public static final DISCOVERY_URL that it passes to discoverConfig. My main hangup, as suggested above, is that to implement the caching, I want to ensure that the model configuration is stored/set in the right place. Thanks for bearing with me as I come up to speed on this! James