OAuth provides only and should only provides authorization using an access token. OpenID connect is built on OAuth 2 in order to provide user authentication information. However, it will not provide you a more robust implementation than OAuth (since it uses OAuth and add some extra interactions with a OpenID provider).
OpenID Connect 1.0 is a simple identity layer on top of the OAuth 2.0 [RFC6749] protocol. It enables Clients to verify the identity of the End-User based on the authentication performed by an Authorization Server, as well as to obtain basic profile information about the End-User in an interoperable and REST-like manner.
OpenID Connect Core 1.0 - draft 17
Things is, OpenID connect provides you a "standard" way to obtain user identity. If you use OAuth and the API, you should adapt your request for each resources, which may not always provide the same information or may change over the time. And conceptually, you use OAuth to be allowed to use an API, not to authenticate an user.
As background, the OAuth 2.0 Authorization Framework [RFC6749] and OAuth 2.0 Bearer Token Usage [RFC6750] specifications provide a general framework for third-party applications to obtain and use limited access to HTTP resources. They define mechanisms to obtain and use Access Tokens to access resources but do not define standard methods to provide identity information. Notably, without profiling OAuth 2.0, it is incapable of providing information about the authentication of an End-User. OpenID Connect Core 1.0 - draft 17
Note that, OpenID connect provides an
id_token with some information about the user. However, if you want the whole set of information, you still need the
access_token to request the OpenID provider to get the userinfo (which confuse me the first time I see it). That shows that request user information from an API or from the OpenID provider use almost the same method. See
5.3.1. userinfo request in the draft.