Re: [OAUTH-WG] Report an authentication issue

[prateek mishra <[e-mail]>]

Adam,

I agree with you that this is a significant use-case, one that is of 
particular interest for enterprise deployments.

My impression is that the fully specified OAuth flows to date focus on 
certain key consumer-centred use-cases and that important enterprise 
flows such as the one you have
described are yet to be profiled. We havent looked at OpenID Connect 
yet, but I dont believe  this was the main use-case for that effort either.

I support your call for a broader discussion of this issue.


- prateek



> 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]]
> *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] 
> <mailto:[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] <mailto:[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]> 
> [mailto:[e-mail] <mailto:[e-mail]>] *On 
> Behalf Of *Igor Faynberg
> *Sent:* Wednesday, June 20, 2012 2:39 PM
> *To:* [e-mail] <mailto:[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]> 
> [mailto:[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] <mailto:[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] <mailto:[e-mail]>>
>     *To:* rui wang <[e-mail] <mailto:[e-mail]>>
>     *Cc:* matake nov <[e-mail] <mailto:[e-mail]>>; Yuchen
>     Zhou <[e-mail] <mailto:[e-mail]>>;
>     oauth <[e-mail] <mailto:[e-mail]>>; Shuo Chen (MSR)
>     <[e-mail] <mailto:[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]
>     <mailto:[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] <mailto:[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] <mailto:[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] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
>
> _______________________________________________
> OAuth mailing list
> [e-mail] <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]  <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
>
>   
>   
> _______________________________________________
> OAuth mailing list
> [e-mail]  <mailto:[e-mail]>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail] <mailto:[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