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 < [email protected]> 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":"[email protected]", > "aud":" https://[email protected]";, > "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:* [email protected] [mailto:[email protected]] *On Behalf > Of *Igor Faynberg > *Sent:* Wednesday, June 20, 2012 2:39 PM > *To:* [email protected] > > *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:* [email protected] > [mailto:[email protected]<[email protected]>] > *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 <[email protected]> > 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 <[email protected]> > *To:* rui wang <[email protected]> > *Cc:* matake nov <[email protected]>; Yuchen Zhou <[email protected]>; > oauth <[email protected]>; Shuo Chen (MSR) <[email protected]> > *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 <[email protected]> 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth**** > > > > **** > > **** > > -- > Nat Sakimura (=nat)**** > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en**** > > **** > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > **** > > > > **** > > **** > > -- > Nat Sakimura (=nat)**** > > Chairman, OpenID Foundation > http://nat.sakimura.org/ > @_nat_en**** > > **** > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth**** > > **** > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth**** > > **** > > > > > **** > > _______________________________________________**** > > OAuth mailing list**** > > [email protected]**** > > https://www.ietf.org/mailman/listinfo/oauth**** > > > > **** > > ** ** > > ** ** > > _______________________________________________**** > > OAuth mailing list**** > > [email protected]**** > > https://www.ietf.org/mailman/listinfo/oauth**** > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
