Can they be used together? ....or are they two separate protocols that may or may not be useful depending on the context?

The reason I ask is because I'm trying to implement the following:

  1. User "Bob" goes to a Client implemented as a User-Agent only application.
  2. The protected resources are controlled by the same domain as the authentication/authorization server, but they are on different subdomains. However, no session is found in the cookies, so...
  3. Bob clicks "login," and gets redirected to authorization/authentication server using something like the following:

    GET https://accounts.example.com/authorize?response_type=token&client_id=123&redirect_uri=http://original.example.com&scope=openid profile token custom
  4. Bob is given a list of options to choose from to authenticate, i.e., "example, google, twitter," etc. which leads to his authentication at example.com, which in turn is used for his authorization for a specific API hosted by example.com.

Should I be using OpenID Connect, OpenID 2.0, both? What? This is my first time implementing any of them. I'm only asking about the authentication part of this. I'm just trying to get Bob authenticated so that I can move on to issuing the token to the client.

3 Answers 3


I don't think either of the other previous responses answer the question, which is asking the difference between OpenID Connect and OpenID 2.0. OpenID 2.0 is not OAuth 2.0.

OpenID 2.0 and OpenID Connect are very different standards with completely different parameters and response body formats. Both are built on top of OAuth 2.0 by putting additional values into otherwise valid OAuth 2.0 requests and responses, in order to provide identity information needed for authentication (whereas OAuth 2.0 only provides authorization, not authentication). OpenID Connect improved naming and structure of OpenID 2.0 fields and parameters in order to be easier to use. I can easily read the OpenID Connect specification and understand what all the values are used for and what to set them to, but trying to read the OpenID 2.0 specification is a bit more difficult and convoluted.

At this point the choice is easy, OpenID 2.0 is deprecated. You should use OpenID Connect.

  • 7
    The only answer that answers the question May 17, 2018 at 13:18
  • Agreed. I think people should spend the time reading and understanding the question before answering.
    – Adrian Teh
    May 8, 2019 at 19:27
  • Looking through OpenID FAQ, openid.net/connect/faq, OpenID Connect is the newer protocol then OpenID 2, so it make sense we should use Open ID Connect instead of OpenID 2 Oct 6, 2019 at 14:30
  • can I conclude that Open ID Connect is used for both authentication and authorization? or I should use Open ID Connect for authentication only and also implement OAuth2 for authorization?
    – Kid101
    Jan 13, 2020 at 12:00
  • 1
    @theferrit32 Where do you find that OpenID 2.0 is deprecated? It looks like it is still alive and kicking to me. Mar 29, 2021 at 11:44

OpenID and OpenID Connect are both for authentication, not for authorization. The two activities are distinct. OpenID Connect is in fact OAuth (an authorization protocol) which is turned (abused) into an authentication protocol. More explanations in this answer.

To some extent you can mix authentication and authorization, but that's a source of confusion. In your case, you apparently want to authenticate users with "Google, Twitter,...": you want Google (or Twitter) to tell you who the user is, but not what the user should be allowed to do; you want these external providers for authentication, not authorization.

Another way to see it is the following: a user connects to your server S. Server S offers some "services", i.e. will do "things" when asked for; however, it won't accept to do the same things for everybody. Let's assume that you found it fit to give control of what S may do or not for each user to another system which we will call R. R may or may not be the same computer as S, but let's think generically and assume that R is distinct from S. From the point of view of S, the needed information is in scope of authorization: S wants to know whether the call is to be granted or not. So there will be some authorization protocol going on between S and R. Possibly, S and R won't talk directly to each other, but only through messages ("tickets") which are transported by the client; that's a technical detail.

However, to decide whether a given request to S should be allowed or not, the authorization server R must know who is sending the request, because the answer depends on the user's identity. Therefore, R will need to authenticate the user; or, more generically, to talk to an authentication server T. T is responsible for making sure that the user is indeed who he claims to be. An authentication protocol then occurs between R and T.

In your example, R is your authorization server, while T is Google/Twitter. You would use OpenID between R and T, and OAuth between S and R.

OpenID Connect is when S wants to do some authentication as well; S then uses R (who "speaks OAuth") and infers that if R allows the request, then R must have done some sort of authentication of the user; so S decides that the user is indeed who he claims to be, since it (implicitly) convinced R.

  • 1
    This bit threw me off a little, because I think OpenID Connect and OAuth are not precisely equivalent: "OpenID Connect is in fact OAuth (an authorization protocol) which is turned (abused) into an authentication protocol.". From what I can tell from oauth.net/articles/authentication, OpenID Connect deals with some of the pitfalls that would be encountered using plain OAuth for pseudo-authentication
    – ossek
    Jan 17, 2017 at 22:56
  • 2
    @ossek You are correct. I would not classify OIDC as an "abuse" of OAuth. I feel that word is probably misleading as well. OIDC is built on top of OAuth. It uses OAuth to authorize the client service (S in the above example) to access the calling user's identity.
    – Pace
    Mar 12, 2018 at 17:19
  • I would also rephrase the last paragraph as. “With OIDC there is another service I that S trusts. This service can tell you the identity of the current user. S wants to ask I for this identity. I must first authorize that S is allowed access to that identity. This authorization is done with OAuth (e.g. S gets a key from R and sends it to I and I verifies that key with R before answering).
    – Pace
    Mar 12, 2018 at 17:54
  • @ThomasPornin, you need to be more explicit in differentiating between OAuth and OAuth2. OpenID Connect is build on top of OAuth2.
    – Jacco
    Feb 19, 2019 at 11:47

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. OpenID connect is in fact the child of OpenID. See OpenID-Connect-Lecture-for-MIT, slide 33

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 obtains user identity. If you use OAuth and the API, you should adapt your request for each ressources, 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. But if you want the whole set of information, you still need the access_token to request the the OpenID provider to get the userinfo (which confuse me the first time I see it). See 5.3.1. userinfo request in the draft

  • The link is broken
    – nafg
    Jun 26, 2015 at 6:53
  • 3
    This answer doesn't mention how how they are different. Nov 21, 2016 at 21:36
  • One is for authorization, one for authentication
    – Nereis
    Nov 24, 2016 at 13:12

You must log in to answer this question.

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