I have to admit I'm a little confused about the relationship between OpenID and OpenID Connect. At any rate, OIDC is a restricted, but still standards conformant, profile of OAuth 2 designed specifically for authentication:
Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself. (http://openid.net/connect/)
I can't find any direct assurance on the OpenID Connect website that a conformant OIDC implementation will by definition be compatible with a compliant OAuth2 implementation, although I suspect this is due to the open-ended nature of the OAuth 2 standard (i.e. I'm not sure if you could confidently say any particular implementation of OAuth2 would be compatible with another implementation). FWIW, you can implement an OIDC 'relying-party' directly on top of google's social auth OAuth 2 endpoint, if I'm reading this correctly: https://developers.google.com/identity/protocols/OpenIDConne...
Unless much has changed in the past year or so, it's also very easy to do a relying-party implementation, which I think matches your scenario. For example, I wrote a (probably insecure) relying-party implementation straight from the spec in a bit less than a day, and I'm not a programmer by trade.
It worked when tested against one of the django OIDC libraries floating around out there, which came as a bit of a shock. This might suggest the standard is 'tight' enough to ensure interoperability between independent implementations. Then again, it's only one data point so YMMV.
Whereas integration of OAuth 1.0a and OpenID 2.0 required an extension, in OpenID Connect, OAuth 2.0 capabilities are integrated with the protocol itself. (http://openid.net/connect/)
I can't find any direct assurance on the OpenID Connect website that a conformant OIDC implementation will by definition be compatible with a compliant OAuth2 implementation, although I suspect this is due to the open-ended nature of the OAuth 2 standard (i.e. I'm not sure if you could confidently say any particular implementation of OAuth2 would be compatible with another implementation). FWIW, you can implement an OIDC 'relying-party' directly on top of google's social auth OAuth 2 endpoint, if I'm reading this correctly: https://developers.google.com/identity/protocols/OpenIDConne...
Unless much has changed in the past year or so, it's also very easy to do a relying-party implementation, which I think matches your scenario. For example, I wrote a (probably insecure) relying-party implementation straight from the spec in a bit less than a day, and I'm not a programmer by trade.
It worked when tested against one of the django OIDC libraries floating around out there, which came as a bit of a shock. This might suggest the standard is 'tight' enough to ensure interoperability between independent implementations. Then again, it's only one data point so YMMV.