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]>
[mailto:[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]<mailto:[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]<mailto:[email protected]>>
To: rui wang <[email protected]<mailto:[email protected]>>
Cc: matake nov <[email protected]<mailto:[email protected]>>; Yuchen Zhou
<[email protected]<mailto:[email protected]>>; oauth
<[email protected]<mailto:[email protected]>>; Shuo Chen (MSR)
<[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
