Re: [OAUTH-WG] Report an authentication issue

[Nat Sakimura <[e-mail]>]

On Fri, Jun 22, 2012 at 4:59 AM, Paul Madsen <[e-mail]> wrote:

> **
> Lewis, I think you are perhaps conflating the token model (whether it has
> inherent structure or is merely a pointer to user info) and who the RO
> owner is - user or enterprise.
>
> Nothing prevents you today from using OAuth as is to issue a token to the
> officer on the tablet, having the app use that token on API calls, and the
> API making an authz decision based solely on enterprise policy, with no
> consent figuring in.
>

Indeed, though I usually envisage that there is invisible consent authority
a.k.a. corporate policy engine.


>
> Neither do you need a structured token (like id_token). The token issued
> can merely be a pointer/artifact to the officer's actual roles, these
> obtained by the API/RS by sending the tokens for 'validation' or
> 'introspection'
>

If RS can reach AS through network, yes, the access token can act as an
artifact that you do artifact resolve. That would have a nice property of
audit logging at the AS. It is not always true though. In one of my use
case, RS was not able to directly talk to AS, in which case, you need a
structured token.


>
> This doesnt sound like a Connect Use Case to me - rather a pretty standard
> OAuth use case - albeit with no need to get user's consent (so actually
> simpler).
>

If authentication and the identity of the accessor matters, yes.
If it does not, maybe not.


>
> paul
>
>
> On 6/21/12 12:01 PM, Lewis Adam-CAL022 wrote:
>
>  Hi Nat,****
>
> ** **
>
> I’m beginning to wonder what it would take to add a new profile of sorts
> to either OAuth or Connect.  ****
>
> ** **
>
> In the beginning there was SOAP, and the preferred method to secure SOAP
> API calls was WS-Trust.****
>
> ** **
>
> Now the world is moving toward RESTful APIs … and the preferred means to
> secure RESTful APIs is OAuth.****
>
> ** **
>
> Except that OAuth is clearly written with the idea that the protected
> resources belong to the end user.****
>
> ** **
>
> My use cases – and I imagine the use cases of many other enterprises – is
> that the Owner of the resources is the Enterprise.  An employee is trying
> to access a database or video resources.  The enterprise RS needs to be
> able to 1) identify the user, and 2) make authorization decisions based on
> what roles that user has within the enterprise.  So in my scenario, when a
> police officer attempts to access a criminal records database, the database
> needs to know who that officer is, and then decide if they have privilege
> to access the database, and at what level (e.g. CRUD).  ****
>
> ** **
>
> WS-Trust fits this model well.  The user performs primary authentication
> to the enterprise STS, which then grants the application client a SAML
> assertion.  When the user attempts to access a records database, the SAML
> assertion is included in the SOAP message.  The records server
> authenticates the user based on the SAML assertion and makes its
> authorization decisions.****
>
> ** **
>
> This is the world I’m trying to migrate from, and it really seems like I’m
> sometimes trying to make a square peg fit in a round hole.  I’m looking for
> OAuth/Connect to do for REST what WS-TRUST did for SOAP.  I would like a
> native client talking to a RS to be able to ask for an id_token, and then
> pass that id_token to the RS when making its RESTful API calls, to enable
> the RS to authenticate the user.  I think that this would be really useful
> for a lot of people besides me.  I keep hearing that there is nothing
> “preventing” me from doing this … but it hardly seems within the spirit of
> what OAuth was meant to do.  The id_token was clearly meant to enable a
> user to authenticate to a confidential client  / web server … but was not
> meant for a native client to identity / authenticate the user to a RS.  **
> **
>
> ** **
>
> ** **
>
> Would there be any interest in exploring this further?****
>
> -adam****
>
> ** **
>
> ** **
>
> *From:* Nat Sakimura [mailto:[e-mail] <[e-mail]>]
> *Sent:* Wednesday, June 20, 2012 8:09 PM
> *To:* Lewis Adam-CAL022
> *Cc:* [e-mail]; [e-mail]
> *Subject:* Re: [OAUTH-WG] Report an authentication issue****
>
> ** **
>
> 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****
>
> ** **
>
>
> _______________________________________________
> OAuth mailing [e-mail]://www.ietf.org/mailman/listinfo/oauth
>
>


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