Indeed, it is assumed that any given provider will only be one type of provider. In most cases, this is a perfectly valid assumption; clearly in your case it isn't correct. Likewise, with Google it isn't correct either, as Google supports both OAuth 1 and OAuth 2 for authorization. In the Google case, the choice between OAuth 1 or OAuth 2 ultimately has little or no bearing on how you use their APIs, so it's only necessary to focus on one of those (and OAuth 2, being the simpler of the two, is the most logical choice).
In your case, are there reasons you might choose OAuth 2 in some cases and OpenID Connect in other cases? If not, then you can choose one and go with it. If there is, however, then you would need to have two separate service provider implementations and two separate connection factory implementations, but not necessarily two completely duplicate modules. Those two specific implementations could still be in the same module alongside a common API binding.
The only possible complication I see is if working with the API is different for OAuth 2 than it is for OpenID Connect. My understanding of OpenID Connect is that it wouldn't be much different, if at all, and you should be able to extend your base API binding class from AbstractOAuth2ApiBinding and it work otherwise as if the authorization was done via OAuth 2 (after all, OpenID Connect authorization is just OAuth2 authorization with a bit of extra info coming back with the access token). But if I'm wrong and it requires more than just the access token after having authorized via OpenID Connect, then you can still create a common binding, but may not be able to base it from AbstractOAuth2ApiBinding. At this point, I'm just speculating, though...I don't know enough about your specific problem to know if this is even something you must worry about or not.
Spring Social Project Lead