I just started to use OAuth 2.0 as a way to authenticate my users. It works great - I just use the identity/profile API of each provider to get a validated email address of the user.

Now I read about OpenID Connect and am a little bit confused.

What is the difference between OpenID Connect and using the identity API over OAuth2? Is it just that I have a standard profile API, so that I don't have to worry whether I get an "email" or an "emails" JSON back?

Or is there more to it, which makes the OpenID Connect approach more secure than my first approach?

  • 1
    Alright, I didn't know about "OpenID Connect", I understood it as "OpenID" + "Connect". I'm sure you've already checked this: softwareforallseasons.blogspot.fr/2011/10/… + I suggest you edit your question so that it reads OAuth 2.0 instead of just OAuth.
    – Aki
    Commented Jun 21, 2013 at 15:04
  • @Aki: yes, I've seen the blog post, but couldn't make anything of it.
    – rdmueller
    Commented Jun 22, 2013 at 20:55
  • 1
    @Ralf: As I see it, you can build apps with oauth and authorize sharing or not of specific resources linked to the user account. Using openid connect, it is made easier, the provider doesn't have to implement its own layer above oauth to handle it and clients have a standard way to access data.
    – Aki
    Commented Jun 26, 2013 at 8:06
  • "I just use the identity/profile API of each provider to get a validated email address of the user." This means that you need to restrict the set of allowed providers. An arbitrary provider doesn't guarantee validation. Alternatively you could reject email addresses that don't match the domain of the provider. Commented Nov 10, 2013 at 15:16
  • 3
    As an article on oauth.net states: OAuth 2.0 is not an authentication protocol. It's actually authorization framework. They recommend using OpenID Connect (which is based on OAuth 2.0) if you want authentication.
    – Jonas
    Commented Aug 11, 2016 at 8:47

7 Answers 7


This article is the best explanation I've found after a LOT of searching (h/t to @rickchristie for linking to it in a comment to another answer).


Relying on plain OAuth 2.0 for authentication is dangerous if you (the client) are just trusting ANY valid access token you receive that's associated with that user as a reliable indicator that you're receiving the request from the actual user, without knowing whether that access token was generated by the user trying to log into your site or if it was generated by the user logging into some other (malicious) website/app.

With OpenID Connect, you can just look inside the JWT ID token provided by incoming requests and see if that token was generated by the user logging into your app or if they were logging into some other web app.

But if you're using the "authorization code flow", i.e. the user is being directed to send your back-end the authorization code and your back-end is trading that for the access token, and then your back-end is saving a record of those access tokens, or if you are issuing the user a signed JWT that contains the access token you generated on their behalf, then you can just check any incoming request to see if the provided access token is one that you have generated, thereby preventing malicious apps from impersonating your user with an access token that was created when the user logged into the malicious app.

If you do that check, you don't need to use OpenID Connect to avoid that kind of attack. But it seems that for some use-cases (e.g. pure-frontend auth libraries) this method of saving and checking access tokens is either not possible or not convenient, and it's for those use-cases that OpenID Connect is necessary.

Key quotes from the article

  • "So [when using only OAuth 2.0] we wind up in the situation where any site the user logs into with their Facebook account can impersonate that user at any other site that accepts Facebook logins through the client-side flow (the default for Facebook). The less common server-side flow is more secure, but more complicated."
  • "The client has no way to tell who the authorization server thought it was issuing that access token to."
  • 2
    thanx. this is quite valuable. I wonder if I can/should change this to the valid answer... what will happen?
    – rdmueller
    Commented Mar 20, 2022 at 21:19
  • @rdmueller My understanding is that the recommended practice on Stack Overflow is to set the best answer to be the 'accepted answer'. But I think SO will still generally show the top-rated answer at the top(?). Commented Mar 20, 2022 at 21:31
  • 1
    Let's give it a try...
    – rdmueller
    Commented Mar 21, 2022 at 7:23
  • The article you link to is very old. It predates the finalization of the OAuth 2.0 RFC. It talks about Facebook, which is not OAuth 2.0 compliant, especially the client-side flow. Injecting an access token for another client is not possible with the authorization code flow, only the insecure implicit flow (which will be removed from OAuth 2.1). State-to-cookie binding is not necessary for protecting against this attack. State binding helps prevent CSRF attacks where you do a redirect to the authorization server and expect an auth code before performing sensitive operations.
    – Boaz Yaniv
    Commented Sep 28, 2023 at 5:09
  • @BoazYaniv Thanks for your comment. I'm honestly finding it hard to follow what you're saying. What is "state-to-cookie binding" and "state binding"? Commented Sep 28, 2023 at 14:25

OpenID connect will give you an access token plus an id token. The id token is a JWT and contains information about the authenticated user. It is signed by the identity provider and can be read and verified without accessing the identity provider.

In addition, OpenID connect standardizes quite a couple things that oauth2 leaves up to choice. for instance scopes, endpoint discovery, and dynamic registration of clients.

This makes it easier to write code that lets the user choose between multiple identity providers.

  • Are you sure your statement "OpenID connect will give you an access token plus an id token." is correct? I thought an application can have an id_token and share it with a different application and then get an access token from that application. OIDC rides on top of the OAuth2 protocol but you don't necessarily get both. Although, it may happen most of the time. Commented Dec 17, 2018 at 18:08
  • "OpenID connect will give you an access token plus an id token." >> For most cases this is correct and the way it's usually handled. You make one request that consists of "token id_token" as responseTypes and "openid" as scope, which will return both an access token and an id token at the same time. The ID token is meant to be for the client, while the access token is meant to be opaque to the client and is meant to be passed on in requests to the resource server to protect, such as an API or other backend. Commented Apr 8, 2019 at 9:30
  • "I thought an application can have an id_token and share it with a different application and then get an access token from that application." >> You don't exchange an ID token for an access token, if that's what you meant. And both is issues by the authorization server / IdP, not from another application or resource server (although authorization server and resource server can sometimes be the same). Commented Apr 8, 2019 at 9:31

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

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 resource, 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 confused me the first time I saw it). That shows that requesting user information from an API or from the OpenID provider use almost the same method. See 5.3.1. userinfo request in the draft.

  • This answer is absolutely correct. Just wanted to point one minor thing out: "However, if you want the whole set of information, you still need the access_token to request the OpenID provider to get the userinfo" >> this isn't necessarily the case depending on the authorization server/broken used: it's also possible to already include the full profile inside the ID token = JWT token, or even any other information using custom claims; an example being auth0.com/docs/tokens/id-token#add-custom-claims. Then you don't need to do the /userinfo request anymore. Commented Apr 8, 2019 at 9:34

OAuth is an authorisation protocol, providing a way to give authorisation to access a protected resource. A by-product of the authorisation process is that the user is authenticated.

Technically, OAuth does not have to give you any information about the user. What it provides is a validation that the user has given authority to the application to access some data. This is governed by the scope of the authorisation grant.

OpenID Connect provides a way for the application to retrieve information about the authenticated user. Most importantly it provides a level of assurance that the information is valid (as far as the authorisation server is concerned anyway). This can then be used to facilitate identity federation.

In the past, federation was achieved with OAuth by granting a scope that allowed access to the user's identity information. OpenID Connect standardises that scope.

  • 2
    The external provider still needs to support opend Id right? You can't just implement open id on top of existing oauth 2 providers as a client of those external services. Commented Mar 13, 2017 at 6:22

OpenID Connect is a profile of OAuth2... defining an architecture that enables a person to authorize an identity provider to release certain user claims to a client (website / mobile application).

OAuth2 offers the Resource Owner Password Credential Grant, which is rightly maligned by IAM experts as "The Devil".

A common pattern for OpenID Connect API is three steps:
1) Get a code
2) Get tokens like the access_token, refresh_token, and id_token
3) Get user info which contains claims like username, email, etc.
The schema for the id_token, which is a JWT, is defined in the OpenID Connect scope, as are many other details.

Another reason to use OpenID Connect is that there is a secure solution for centralized authentication for mobile software (at least IOS and Android). The current best practice defined by Google is to use new security features that block a mobile application from seeing cookies or credentials in a web view. Google published the AppAuth IOS and Android libraries because they really don't want you to leak Google credentials! As of the time of this writing, there are several OpenID Providers (aka IDP's...) that support the Google OpenID Connect AppAuth software, including: Google, OKTA, Ping, and my product Gluu.

See Also:

  • OAuth 2.0 for Native Apps draft-wdenniss-oauth-native-apps-02
  • AppAuth for IOS
  • AppAuth for Android

Using OAuth as an authentication method is not recommended, it is explicitly designed as a delegated authorisation method.

Facebook was using OAuth as an authentication method, but an enterprising person discovered how to steal the access_token from Facebook - full blog entry

OpenID Connect makes it much more difficult to steal access tokens through such a mechanism.

  • thanx for the link - have to check what makes the difference...
    – rdmueller
    Commented Dec 24, 2015 at 12:05
  • 6
    OK. Read the blog entry. For me, this reads like facebook implemented some security holes, but not that OAuth is broken... So, when I use the OAuth scheme where I have to verify the access token server-to-server, the problem described in the blog couldn't have shown up... I am still convinced that OAuth - implemented the right way - is quite good...
    – rdmueller
    Commented Dec 26, 2015 at 22:06
  • 3
    This one is better in explaining why using OAuth as authentication mechanism creates security hole: thread-safe.com/2012/01/… Commented Mar 15, 2017 at 10:19

Open id connect is build on the top of OAuth and hence it's more robust. OAuth is the protocol which is used only for the authorization and open id connect is very similar to OAuth but it combines the feature of OAuth also. You can start communication between your RP's and IP's using this protocol and their are various loop holes in OAuth protocol that's why better to use Open Id Connect.

  • Would be interesting to know why this answer got a downvote...
    – rdmueller
    Commented Oct 11, 2013 at 18:18
  • 2
    which loopholes are you referring to (honest curiosity).. I'm struggling with the same question as the OP. It seems oAuth2 (on which Openid Connect is based) already does authentication, although I'm familiar with the session-hijacking and MiM replay attackes possible with simple Bearer tokens. Are these the loopholes you're referring to?
    – Geert-Jan
    Commented Oct 29, 2013 at 20:48
  • 7 years later... those loopholes surely aren't solved by OIDC though? You still have access tokens after all, and they still do the same thing they were supposed to do in OAuth2 in OIDC? It seems to me like if you have flaws in your implementation of OAuth2, layering OIDC on top isn't going to solve those problems.
    – Seer
    Commented May 28, 2020 at 8:47
  • 1
    "Would be interesting to know why this answer got a downvote" - probably because saying A is built on top of B and that's why A is more robust than B is a worrying opener.
    – Rob Grant
    Commented Jun 26, 2023 at 22:35

You must log in to answer this question.

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