How to "upgrade" 3rd Party Authentication from social_core.backends BaseOAuth2 to OpenIdConnectAuth?

[Stan V]

A number of modern User Management systems use OpenID Connect exclusively for 3rd party authentication vs. the base OAuth2. The social_core package employed by edx-platform provides the means of integrating with those systems via class OpenIdConnectAuth(BaseOAuth2).
As the current master edx-platform code requires that the 3rd party auth packages implement BaseOAuth2 and there seems to be not much extra for the social_core consumer app to do calling OpenIdConnectAuth vs. BaseOAuth2 - sounds like simply replacing references to BaseOAuth2 with OpenIdConnectAuth in edx-platform would be a reasonable path to try. However, as edx-platform works with a number of super classes relatively to BaseOAuth2 in various forms, there are quite a few places that need to be reviewed and interrogated applying the OpenIdConnectAuth "upgrade".
Has anyone succeeded running, e.g., social_core.backends.google_openidconnect.GoogleOpenIdConnect as the 3rd party auth method from edX or has a clear scope of how the 3rd party auth info is being processed by the edx-platform, from the setup through the auth completion, relatively to the use of BaseOAuth2 and its super classes? This link is very detailed but quite outdated, unfortunately:

http://johnmcox.blogspot.com/2014/05/understanding-edx-third-party.html

[Stan V]

After some debugging: social_core.backends.google_openidconnect.GoogleOpenIdConnect works as-is, no change to the code is needed. 

The issue I initially was running into is the same as mentioned in another recent post: when configuring the 3rd party provider, the "slug" must match the "backend_name". The latter is the one being passed into the process from the login form, and the former is the key in the table. The way the custom edx django-config model works, if the record is not found in the database, it returns a "new" object, which then errors out in the third_party_auth/strategy.py with the message "Can't fetch setting of a disabled backend/provider". After shaking off the initial confusion that there was something related to the social class mismatch and making the slug=backend_name - the Google OpenId Connect authentication worked. The setup is the same as for the Google OAuth2.