Since OpenID Connect builds on OAuth 2.0, I am assuming that everything that is possible with OAuth 2.0 is also possible with OpenID Connect.

In particular, say that my website stores some information that belongs to the user and implements OpenID Connect to authenticate users. When the user is authenticating through another website, that website can use the same OpenID Connect flow to obtain authorization from the user to give it access to that user's information on my website.

Is that statement correct? Could there be any scenario where I would need to implement OAuth 2.0 independently of OpenID Connect?

1 Answer 1


Short answer is that it is undefined. If you want a library that supports both, ensure it explicitly states it supports both OAuth 2 and OIDC.

If you were to draw a Venn diagram, OAuth 2 and OIDC intersect each other but OAuth 2 also defines some flows that OIDC does not extend, and OIDC adds a flow that is not in OAuth 2.

OAuth 2 flows:

  • Authorization Code Grant
  • Implicit Grant
  • Resource Owner Password Credentials Grant
  • Client Credentials Grant

OIDC flows:

  • Authorization Code Grant
  • Implicit Grant
  • Hybrid

The OIDC specification explicitly extends OAuth 2's authorization code and implicit flows, but says nothing about the others. Therefore a given OIDC implementation may fully or partially or not support the remaining OAuth 2 flows. By partially I mean, it only returns the access token as per OAuth 2, but not ID token.

So why doesn't OIDC explicitly cover all OAuth 2 flows? Here's what I think:

  • Resource Owner Password Credentials Grant. This flow defeats the security features introduced by OAuth 2's authorization code grant. From a security perspective, stay away from this flow.
  • Client Credentials Grant. One example of this scenario is service to service communication, which could be solved with PKI - does not need ID token introduced by OIDC.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .