Re: [OAUTH-WG] Report an authentication issue

[Nat Sakimura <[e-mail]>]

Yes, OAuth can be profiled to enable authentication.
In fact, initial draft of OpenID Connect was just like you described.
Essentially, we were using structured access_token.
Later, we decided to separate the access token and id_token for several
reasons such as:


   1. Better interop with existing OAuth implementations: by introducing
   id_token, they do not need to touch the supposedly opaque (which means
   AS-RS may be doing some proprietary thing inside it) access token.
   2. Mixing up the audience (for id_token aka authn = client, and for
   access_token aka authz = resource server) probably is expanding the attack
   surface for security and privacy.

Although we separated them out, a signed id_token includes the left hash of
access_token so access_token is also protected.

Best,

Nat

On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 <
[e-mail]> wrote:

>  Hi Igor,****
>
> ** **
>
> As Justin just pointed out, consider the case where the video server is
> hosted by the state (e.g. California) and is accessed by police agencies in
> Los Angeles, San Francisco, and San Diego.  The State of California’s video
> server is the RS.  Each local police agency (LA/SF/SD) hosts an AS.  So
> when a police officer from LAPD launches the video client app on the
> iPhone, the client makes an OAuth request to the LAPD’s AS, which
> authenticates the police officer using agency level credentials.  The
> access token issued to the video client app on the iPhone is a JWT, signed
> by the agency AS, which might look something like this:****
>
> ** **
>
> {“typ”:”JWT”,"alg":"ES256"}****
>
> {"iss":"https://as.lapd.california.gov",
>   "prn":"[e-mail]",
>   "aud":" https://[e-mail]",
>   "iat":1300815780,
>   "exp":1300819380,
>   "acr":”password”}****
>
>
> hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P53BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7klIz3RqVL+wNmeWI4=
> ****
>
> ** **
>
> The JWT might be optionally encrypted using JWE.  ****
>
> ** **
>
> I think what is becoming clear (and this is what I’m trying to vet) is
> that while there is nothing in OAuth that specifies authentication, it **
> can** be used for Authentication, if done in the way that I describe.  If
> I’m wrong about this, I really need to know.  I’ve vetted this idea of mine
> with quite of few people now – both within context of the list and off-line
> – and I think I’m okay. If you see any holes in what I describe, please
> point them out as I would prefer to uncover them now rather than after
> implementation or deployment!****
>
> ** **
>
> Essentially I’m using OAuth as a RESTful version of WS-Trust, where my
> client can exchange primary credentials for a token (JWT) and present that
> token to a server as secondary authentication.  It’s just that it’s RESTful
> instead of SOAP :-)****
>
> ** **
>
> As Justin as pointed out … I’ve basically made the access-token look like
> the id_token of Connect.  I was actually hoping to lay a path to Connect,
> and use the id_token … until it was also pointed out that the id_token is
> really meant for the consumption of the client, not the RS :-(****
>
> ** **
>
> ** **
>
> ** **
>
> *From:* [e-mail] [mailto:[e-mail]] *On Behalf
> Of *Igor Faynberg
> *Sent:* Wednesday, June 20, 2012 2:39 PM
> *To:* [e-mail]
>
> *Subject:* Re: [OAUTH-WG] Report an authentication issue****
>
>  ** **
>
> But this use case  does need OAuth, period:
>
>
> The video server is under the control of a police agency, and police
> officers must logon to the video server in order to access video content.
>
> There is no delegation here, and there is no need to use third party for
> authentication.
>
> Igor
>
> On 6/20/2012 3:26 PM, Justin Richer wrote: ****
>
> In case it wasn't clear, I want to restate the original problem as best as
> I understand it in a way that hopefully clears it up:
>
> App A and app B are both valid registered OAuth clients to an OAuth
> protected service.
>
> The problem starts when app A gets handed a token that was issued for app
> B and uses it to call an identity API on the OAuth service. Since app B can
> get tokens just fine, they're bearer tokens, this is a fairly basic api
> call, this function works just fine and returns the user info. This makes
> sense, since anyone who holds A's tokens can do whatever A can do on behalf
> of that user. The issues start when app B then decides that since they can
> make a call to the identity API with a token then the user *must* be
> present. In other words, app B is confusing authorization to call an API
> with authentication of the session.
>
> OpenID Connect fixes this missed assumption by binding the ID Token to the
> session and sending it along side the access token, but as you pointed out,
> it's meant for consumption at the client, not the resource server, in
> general. That doesn't mean you can't send it to a resource server for your
> own purposes, of course. That's actually how the session management
> endpoint works in Connect.
>
> This isn't the only way to handle this problem -- if you put some
> structure in your tokens, such as with JWT or SAML, then app A can tell
> that this isn't a token issued to app A, but to app B, so it can call
> shenanigans and reject it then and there.
>
>  -- Justin
>
> On 06/20/2012 10:03 AM, Lewis Adam-CAL022 wrote: ****
>
> I am entirely confused.****
>
>  ****
>
> I understand what everybody is saying for confidential clients, no problem
> here.****
>
>  ****
>
> I fall apart when thinking of iPhone apps.  Consider the scenario where I
> deploy a video server, and write an iPhone app to talk to the video
> server.  The video server is under the control of a police agency, and
> police officers must logon to the video server in order to access video
> content.  So the police office launches their iPhone video client app.****
>
>  ****
>
> If I wanted to solve authentication using “traditional” client-server
> authentication, the user enters their username / password into the client,
> and the client sends the username / password off to the server, which
> authenticates it, or possibly uses HTTP digest.
>
>
> ****
>
> If I wanted to use OpenID, the client would attempt to reach the video
> server (RP), the server would redirect the client to the OP, OP
> authenticates user, and OP redirects client back to the server/RP with an
> assertion that primary authentication was successful.
>
>
> ****
>
> If I wanted to use OAuth, the client would send an authorization request
> to the server’s AS, which would authenticate the user of the client, and
> ultimately result in the client possessing an access-token.  My thinking is
> that this access token (let’s assume it’s a JWT) would contain the user’s
> identity, a statement of what type of primary authentication was used (auth
> context), an expiration, and an audience claim.  This sounds a lot like
> authentication to me, and it’s where I get confused.  Is it just because
> OAuth does not explicitly define this?  Is there a threat in using OAuth as
> I describe?
>
>
> ****
>
> If I wanted to use Connect, well I’m not even sure how the id_token as
> defined by Connect helps this use case.  The id_token seems to make sense
> when the client is a confidential web server, but it’s not clear what an
> iPhone app would do with the id_token … it’s the server in the backend that
> needs to authenticate the user, the iPhone app is just an interface to talk
> to the server.  And it seems as I learn more about connect that the
> id_token is not meant to be sent from the iPhone app to the server, just
> the access token.  So it’s really not clear how Connect helps solve
> authentication for an iPhone client app talking to a video server.  If I’m
> sending access-tokens, it’s just OAuth again.****
>
>  ****
>
> What am I still missing?****
>
> adam****
>
>  ****
>
>  ****
>
> *From:* [e-mail] [mailto:[e-mail]<[e-mail]>]
> *On Behalf Of *Kristofor Selden
> *Sent:* Saturday, June 16, 2012 11:33 AM
> *To:* nov matake; oauth
> *Cc:* Yuchen Zhou; Luke Melia; Shuo Chen (MSR)
> *Subject:* Re: [OAUTH-WG] Report an authentication issue****
>
>  ****
>
> Nov demonstrated the problem to us at Yapp and we used solution 4 (because
> the solution is server side and our app was in the app store).****
>
>  ****
>
> FB Connect is authentication *and* authorization, where OAuth 2 is
> concerned only with authorization – I'm not sure that app developers
> appreciate this subtlety.****
>
>  ****
>
> With OAuth 2 you authorize an app to use a protected resource.  With FB
> Connect, you do that, but *also* authenticate with the app you are
> authorizing.****
>
>  ****
>
> So the access_token protects not just the FB resources but the auth end
> point of the authorized app (very common with apps that use the iOS SDK).
>  So now the app needs a way to verify that it was the app that was
> authorized to FB.****
>
>  ****
>
> Solution 4 explanation: on FB you can register a iPhone app and a server
> app with the same client_id and get a client_secret for use on the server.
>  The server side API posts the access_token, client_id, and client_secret
> to https://graph.facebook.com/app<https://graph.facebook.com/app?access_token=YOUR_TOKEN> to verify
> that the bearer token actually belongs to the app that is being
> authenticated before assuming they are authorized to the app's protected
> resources.****
>
>  ****
>
> Kris****
>
>  ****
>
> On Jun 15, 2012, at 8:22 PM, nov matake wrote:****
>
>
>
>
> ****
>
> There are 4 ways to fix this issue.****
>
>  ****
>
> 1. Use response_type=token%20code (It's not in OAuth 2.0 Core, but seems
> best way for interoperability)****
>
> 2. Use singed_request (or some signed token like JWT)****
>
> 3. Use grant_type=fb_exchange_token (Facebook custom way)****
>
> 4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN(Facebook custom way, moreover undocumented API)
> ****
>
>  ****
>
> Two iPhone app developers I reported this issue fixed it by using (4).****
>
>  ****
>
> I also tried to use (1) for my own iPhone app implementation, but
> unfortunately it doesn't work when using authorization codes obtained via
> FB iOS SDK.****
>
> So I'm using (3) in my case.****
>
>  ****
>
> nov****
>
>  ****
>
> On 2012/06/16, at 9:16, Nat Sakimura wrote:****
>
>
>
>
> ****
>
> As to how the fix was done, Nov can provide more detail, but ... ****
>
>  ****
>
> 1. Properly verify the signature/HMAC of the "signed_request". This will
> essentially audience restricts the token. ****
>
> 2. There is an undocumented API for Facebook which returns to whom the
> token was issued. This also audience restricts the token. ****
>
>  ****
>
> The service that fixed took these measures. Note that none of the above is
> defined in OAuth. ****
>
> The same facility was called "id_token" and "check ID endpoint" for OpenID
> Connect. ****
>
>  ****
>
> The scale of the impact is large, too large to disclose the actual names
> in the public list, though, eventually, we would publish them in a paper.
> ****
>
>  ****
>
> Nat****
>
> On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <[e-mail]>
> wrote:
>
>
> ****
>
> Hi Nat and Rui,
>
> Rui, you say that the vulnerability that you found was due to a
> "common misunderstanding among developers", but the attack you
> describe can be carried out against any app that uses the OAuth
> "implicit grant flow", which Facebook calls "client-side
> authentication".  No misunderstanding seems necessary.  What
> misunderstanding are you referring to?  I followed the link in your
> message to the Sophos post, and from there the link to the article in
> The Register.  The article in The Register says that Facebook had
> "fixed the vulnerability promptly".  How did they fix it?  The
> instructions that Facebook provides for implementing "Client-side
> authentication without the JS SDK" at
> https://developers.facebook.com/docs/authentication/client-side/#no-jssdk
> still allows the attack.
>
> Nat, I agree that the blog post by John Bradley that you link to
> refers to the same vulnerability reported by Rui.  You say that some
> apps have issued a patch to fix it.  Could you explain what the fix
> was?
>
> Francisco****
>
>  ****
>   ------------------------------
>
> *From:* Nat Sakimura <[e-mail]>
> *To:* rui wang <[e-mail]>
> *Cc:* matake nov <[e-mail]>; Yuchen Zhou <[e-mail]>;
> oauth <[e-mail]>; Shuo Chen (MSR) <[e-mail]>
> *Sent:* Thursday, June 14, 2012 1:50 PM
> *Subject:* Re: [OAUTH-WG] Report an authentication issue****
>
>  ****
>
> This is a fairly well known (hopefully by now) issue. We, at the OpenID
> Foundation, call it "access_token phishing" attack these days. See:
> http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
> ****
>
>  ****
>
> Nov Matake has actually built the code on iPhone to verify the problem,
> and has notified bunch of parties back in February including Facebook and
> Apple. We have the code that actually runs on a phone, and we have
> successfully logged in to bunch of apps, including very well known ones.
> They were all informed of the issue. Some immediately issued a patch to fix
> it while others have not.  ****
>
>  ****
>
> The problem is that even if these apps gets fixed, the problem does not go
> away. As long as the attacker has the vulnerable version of the app, he
> still can impersonate the victim. To stop it, the server side has to
> completely disable the older version, which means the service has to cut
> off many users pausing business problems. ****
>
>  ****
>
> Nat****
>
> On Fri, Jun 15, 2012 at 2:18 AM, rui wang <[e-mail]> wrote:**
> **
>
> Dear Facebook Security Team and OAuth Standard group,****
>
> We are a research team in Microsoft Research. In January, 2011, we
> reported a vulnerability in Facebook Connect which allowed everyone to sign
> into Facebook-secured relying parties without password. It was promptly
> fixed after reporting. (
> http://nakedsecurity.sophos.com/2011/02/02/facebook-flaw-websites-steal-personal-data/
> )****
>
> Recently, we found a common misunderstanding among developers of
> mobile/metro apps when using OAuth (including Facebook’s OAuth) for
> authentication. The vulnerability resulted from this misunderstanding also
> allows an attacker to log into a victim user's account without password.**
> **
>
> Let's take Soluto's metro app as an example to describe the problem. The
> app supports Facebook Login. As an attacker, we can write a regular
> Facebook app. Once the victim user allows our app to access her Facebook
> data, we receive an access_token from the traffic. Then, on our own machine
> (i.e., the "attacker" machine), we run the metro app of Soluto, and use a
> HTTP proxy to insert the victim's access_token into the traffic of Facebook
> login. Through this way, we are able to log into the victim's Soluto
> account from our machine. Other than Soluto, we also have confirmed the
> same issue on another Windows 8 metro-app Givit.****
>
> The Facebook SDK for Android apps (
> https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to
> have the possibility to mislead developers too. At least, the issue that we
> found is not clearly mentioned. In the SDK, we ran the sample code called
> "Hackbook" using Android Emulator (imagine it is an attacker device). Note
> that we have already received the access token of the victim user from our
> regular Facebook app. We then inject the token to the traffic of Hackbook.
> Through this way, Hackbook app on our own machine recognizes us as the
> victim. Note that this is not a convincing security exploit yet, because
> this sample code does not include the server-side code. However, given that
> we have seen real server-side code having this problem, such as Soluto,
> Givit and others, we do believe that the sample code can mislead
> mobile/metro developers. We also suspect that this may be a general issue
> of many OAuth implementations on mobile platforms, so we send this message
> to OAuth Standard group as well.****
>
> We have contacted the vendors of the two vulnerable metro-apps, Soluto and
> Gavit.****
>
> Please kindly give us an ack when you receive this message. If you want to
> know more details, please let us know.****
>
> Best Regards,
> Yuchen Zhou, Rui Wang, and Shuo Chen****
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>  ****
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> ****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=nat)****
>
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en****
>
>  ****
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ****
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ****
>
>
>
>
> ****
>
> _______________________________________________****
>
> OAuth mailing list****
>
> [e-mail]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> OAuth mailing list****
>
> [e-mail]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth
>
>


-- 
Nat Sakimura (=nat)
Chairman, OpenID Foundation
http://nat.sakimura.org/
@_nat_en