Using plain OAuth 2.0 for authentication would create a security hole big enough to drive a car through.

OAuth 2.0 implicit grant flow A good article by John Bradley [1] says that using RP for authentication opens a huge security hole big enough for a car to drive through. The comments are also worth reading. I checked it out and it seems to be completely wiped out. They need to fix the RP side, so it would be better to make a public announcement as soon as possible. I can't contact them one by one.

 

Check Facebook and all other sites that use OAuth login!

The problem with OAuth for Authentication. | Thread Safe

In some of the feedback I have gotten on the openID Connect spec, the statement is made that Connect is too complicated. That OAuth 2.0 is all you need to do authentication. Many point to Identity Pro…

 

For those who don’t want to read English, here’s a quick explanation:

If you try to "authenticate" using OAuth 2.0's implicit flow, it opens up a huge hole.

This is because cut and paste attacks are possible.

The flow of OAuth authentication is as shown in Figure 1.

At first glance, this doesn't seem like a problem. But that's only if all the sites are "good sites."

Let's say Site_A is actually a bad site, and Site_A manages to get hold of an access_token to impersonate this user.

From then on, Site_A can impersonate this user and log in to any site that uses OAuth authentication.

A non-technical introduction to the differences between OAuth authentication(?) and OpenID As I wrote in the article, I gave out a spare key with no address written on it, so I'm essentially saying that whoever has it is my alter-ego, so this is only natural.

To be more specific,

Site_A uses a browser (User Agent) UA to go to Site_B and try to log in. Site_B then tries to "authenticate" using the same procedure as above. UA receives an access token for Site_B, access_token_B, for the attacker, from the OAuth Authorization Endpoint (Authz), but does not pass this to Site_B. Instead, it passes the access token for the user (= victim) that it just obtained, access_token_A.Site_B has no way of knowing that the token is really meant for Site_A, so it accepts it as its own. AndSite_B then sends the access_token to GraphAPI in an attempt to obtain the victim's email and user_id.There is no way for GraphAPI to know that the token sent by this Site_A is actually from Site_B.Therefore, the GraphAPI will send back the victim’s email and user_id just as Site_A requested.As a result, Site_B will allow the attacker to log in as the victim [5].This flow is shown in Figure 2.

This cannot be prevented even by using the OAuth state parameter to prevent XSRF. In other words, an OAuth 2.0 Client can impersonate anyone who has logged in to that Client (site) and log in to any other OAuth-enabled site.

This is not an OAuth issue.

OAuth is an Authorization Delegation Protocol, a protocol for delegating authorization, not a protocol for user authentication. [5] Frankly speaking, it is wrong to use it alone as a substitute for authentication just because it is convenient.

In fact, Facebook is aware of this too.signed_request They have an API called "http://www.openidconnect.org/." It's almost the same as OpenID Connect [2]. You have to use it to log in with Facebook. You do it with scope=signed_request . But how many people are using it? Are they doing it? Most of them are using it to get an access token. Client side flow (Facebook default) instead of authentication, right?! [7]

Eric Sachs, head of Identity Services at Google, also pointed out the importance of this in a post on John's blog:

A great article by John Bradley about how IdPs using plain OAuth for authentication instead of OpenID Connect are creating a huge security hole. This needs to be repeated everywhere - for IdPs to understand that they are creating security problems for their partners; for RPs to realize that they are undermining their own security by skimping on a few lines of code. A few years ago, when Google released their own API "AuthSub", which is now OAuth, they put a big note at the end of the documentation saying "Do not use this for authentication" for this exact reason. [3]

The cause of the problem is that the audience of an access_token is a resource endpoint, while the audience of a token used for authentication must be a client. Therefore, OpenID Connect issues an id_token with the client as the audience, which is separate from the access_token. The same goes for Facebook's signed_request.

Please fix it properly, everyone. Fixing it means making it compatible with OpenID Connect!

It's not a big deal, so please don't put your users at risk by adding a few lines [4][8].

[1] John Bradley. He is a member of the US government's ICAM, and is writing profiles for IMI, OpenID, and SAML. He is a director of the OpenID Foundation and chairman of the Kantara Initiative Leadership Council. This article is about his attempt to write a profile for OAuth authentication, and his conclusion that "this just doesn't work."

[2] While signed_request uses a signature method unique to Facebook, OpenID Connect uses JWS standardized by the IETF JOSE WG. Also, signed_request includes the access_token itself, but OpenID Connect leaves it out for compatibility with other OAuth 2.0 sites.

[3] Original: Great post by John Bradley on the huge security hole many IDPs have created by using plain OAuth, instead of OpenIDConnect, for authentication. We need to keep hammering away on this point both so IDPs realize the security problems they are creating for their partners, and to get RPs to realize how easily they can compromise their own security just because of the lack of a few additional lines of code. Years ago when Google first launched its proprietary equivalent of OAuth, called AuthSub, we had a big section at the bottom warning people not to use it for authentication for exactly this reason. (source: https://plus.google.com/u/0/102425765611793764729/posts/UKcZQzuvosQ )

[4] It would be fine if nothing would happen if the account was hacked, but if the account stores personal information of users, it would naturally result in a personal information leak.

[5] Bold part, added on 2/3.

[6] (Added 2/3) If an attacker, Site_A, passes on its own access_token to another person, the result is the same as if Site_A passed on the results of its own access. Therefore, from the perspective of the GraphAPI/Resource provider, Site_B using the access_token for Site_A does not pose any increased risk.

[7] (Added 2/17) If you use Facebook's Javascript SDK instead of writing your own code, you are now supposed to use signed_request. Furthermore, unlike the documentation, signed request has been changed since July of last year to include a code instead of an access_token. If most people use the JS SDK and don't write their own code, then the damage to Facebook is not that great. However, iOS SDK and Android SDK do not have such measures in place, so they are dangerous. @nov has filed an incident report with Apple about this.

[8] (Added 2/17) In the first place, it is impossible to pass the access_token passed to Javascript or other programs on the client device to the server side. Some have pointed out that if it is not passed, there should be no problem because the only information that the attacker can obtain is the information on the attacker's device, or the data on the platform side that the attacker was originally authorized to access. I hope this is the case, but for example, Facebook's developer materials (https://developers.facebook.com/docs/authentication/) have a diagram that shows the token being sent to the server.