Subject: [OAUTH-WG] Report an authentication issue

From: rui wang <[email-masked]>
Date: Thu, 14 Jun 2012 10:18:16 -0700

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

---

From: Nat Sakimura <[email-masked]>
Date: Fri, 15 Jun 2012 05:50:50 +0900

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-masked]> wrote:

> 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. (
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth
>
>

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

---

From: Francisco Corella <[email-masked]>
Date: Fri, 15 Jun 2012 13:34:56 -0700 (PDT)

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-masked]>
>To: rui wang <[email-masked]> 
>Cc: matake nov <[email-masked]>; Yuchen Zhou <[email-masked]>; oauth <[email-masked]>; Shuo Chen (MSR) <[email-masked]> 
>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
>
>
>>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,

---

From: rui wang <[email-masked]>
Date: Fri, 15 Jun 2012 15:06:21 -0700

Hi, Francisco

Thank you for your reply. Here is our response for your questions.

Ø  the attack you describe can be carried out against any app that uses the
OAuth "implicit grant flow", which Facebook calls "client-side
authentication".

The main concern we raised here is not about attacking client-side apps. We
don’t think it is a meaningful security consequence when a client-side
application (e.g., a Win8 Metro app, iPhone/iPad app) on the attacker’s
tablet misidentifies the user as the victim user. Therefore, you are right
about “this kind of attack can be carried out against any app  using the
OAuth ‘implicit grant flow’”. In fact we won’t even call this consequence
as an attack.
The real problem is that in multiple occasions, we found that the
server-side authentication logic takes an access token from the client app,
then queries the user's profile data from the IdP in order to
"authenticate" the user into the server. We have confirmed that the servers
for Soluto Metro App, Givit Metro App and EuroCup2012 Metro App make this
mistake. These are apps in the official Windows 8 App Store. We only
sampled a small portion of the available apps, but believe this is a
vulnerability pattern due to a common misunderstanding of the usage of the
access token.

Ø  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.

I am very sorry for the confusion. The link to Sophos has nothing to do
with this problem. It is about another issue we reported last year. I
mentioned this because the email yesterday was sent to Facebook and the
OAuth mailing list at the same time. I was trying to let the Facebook team
know we had previous communication before. I should have removed this part
in the version sent to OAuth. Again, sorry for not removing this reference.
Please ignore it.

Thanks,
Rui
On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corella <[email-masked]>wrote:

>   ------------------------------
> *From:* Nat Sakimura <[email-masked]>
> *To:* rui wang <[email-masked]>
> *Cc:* matake nov <[email-masked]>; Yuchen Zhou <[email-masked]>;
> oauth <[email-masked]>; Shuo Chen (MSR) <[email-masked]>
> *Sent:* Thursday, June 14, 2012 1:50 PM
>
> *Subject:* Re: [OAUTH-WG] Report an authentication issue
>
> 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

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 Jun 2012 15:58:53 -0700

I am a bit confused.

It sounds like you are sniffing a bearer token from an unsecured connection to a resource server and then letting another client use that token.

Is this correct?

Phil

@independentid
www.independentid.com
[email-masked]

On 2012-06-15, at 3:06 PM, rui wang wrote:

> Ø  the attack you describe can be carried out against any app that uses the OAuth "implicit grant flow", which Facebook calls "client-side authentication".
>  
> The main concern we raised here is not about attacking client-side apps. We don’t think it is a meaningful security consequence when a client-side application (e.g., a Win8 Metro app, iPhone/iPad app) on the attacker’s tablet misidentifies the user as the victim user. Therefore, you are right about “this kind of attack can be carried out against any app  using the OAuth ‘implicit grant flow’”. In fact we won’t even call this consequence as an attack.
> The real problem is that in multiple occasions, we found that the server-side authentication logic takes an access token from the client app, then queries the user's profile data from the IdP in order to "authenticate" the user into the server. We have confirmed that the servers for Soluto Metro App, Givit Metro App and EuroCup2012 Metro App make this mistake. These are apps in the official Windows 8 App Store. We only sampled a small portion of the available apps, but believe this is a vulnerability pattern due to a common misunderstanding of the usage of the access token.
>  
> Ø  I followed the link in your message to the Sophos post, and from there the link to the article in
> I am very sorry for the confusion. The link to Sophos has nothing to do with this problem. It is about another issue we reported last year. I mentioned this because the email yesterday was sent to Facebook and the OAuth mailing list at the same time. I was trying to let the Facebook team know we had previous communication before. I should have removed this part in the version sent to OAuth. Again, sorry for not removing this reference. Please ignore it.
>  
> Thanks,
> Rui
> On Fri, Jun 15, 2012 at 1:34 PM, Francisco Corella <[email-masked]> wrote:
> Hi Nat and Rui,
> 
> 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.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 Jun 2012 16:33:12 -0700

That sounds like the recent Twitter / thunderclap issue (thunderclap collected multiple twitter update tokens on a single server to allow simultaneous tweets to occur from huge numbers of twitter accounts).

If BobApp was previously approved as a client and the SP discovered BobApp was mis-behaving (witness the recent thunderclap twitter scenario), the SP can simply revoke to tokens issued to BobApp.

This just demonstrates why a server should never depend on parseable bearer tokens by themselves. SPs should check for token revocation.

Phil

@independentid
www.independentid.com
[email-masked]

On 2012-06-15, at 4:22 PM, Shuo Chen (MSR) wrote:

> The attack does not involve sniffing. It is about an app (let’s call it BobApp) running on victim Alice’s tablet, which is able to get the access token.
> Note that BobApp getting this access token on Alice’s device is NOT a security issue, but the natural consequence of the design of OAuth.
>  
> However, the real problem we concern about is that server-side authentication logic takes this access token from the client app, then queries the user's profile data from the IdP in order to "authenticate" the user into the server. This implementation pattern causes the real security problem, because BobApp could send the token to the attacker Bob, who can now authenticate into the server as Alice on Bob’s tablet.
>  
> Ø  and then letting another client use that token
> So “letting another client use the token” is not THE vulnerability, but an attack step that BobApp voluntarily does to exploit the server-side vulnerability.
>  
> Thanks,
> -Shuo
>  
> From: Phil Hunt [mailto:[email-masked]] 
> Sent: Friday, June 15, 2012 3:59 PM
> To: rui wang
> Cc: Francisco Corella; matake nov; Yuchen Zhou; oauth; Shuo Chen (MSR)

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 16 Jun 2012 09:16:42 +0900

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

---

From: Francisco Corella <[email-masked]>
Date: Fri, 15 Jun 2012 17:27:22 -0700 (PDT)

Hi Rui, my fault about the Sophos link.  I hadn't read your message carefully enough, otherwise I would have realized that it was unrelated.    - Francisco

> From: rui wang <[email-masked]>
>To: Francisco Corella <[email-masked]> 
>Cc: Nat Sakimura <[email-masked]>; matake nov <[email-masked]>; Yuchen Zhou <[email-masked]>; oauth <[email-masked]>; Shuo Chen (MSR) <[email-masked]> 
>Sent: Friday, June 15, 2012 3:06 PM

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 16 Jun 2012 09:30:25 +0900

No. You do not need the sniffing in an unsecured connection.

But I am not sure if I should disclose the detail of the attack here in the
public list as that will open up a much more serious attack vector than
leaked passwords hash in recent incidents.

OAuth is not an authentication protocol. It is an access delegation
protocol.
The fact that one has an authorization to access an API does not mean that
he is the subject.
There are bunch of assumptions that have to be fulfilled for OAuth to act
as an entity authentication.
If you pass a token from a client to another, e.g., from an APP to the
server side component, the assumption is violated.
And, this is not only the condition, but there are others as well.

That's why we have been creating OpenID Connect. OpenID Connect adds bunch
of restrictions on OAuth 2.0. They are the things you have to do before you
can use OAuth 2.0 as an authentication protocol.

Best,

Nat

On Sat, Jun 16, 2012 at 7:58 AM, Phil Hunt <[email-masked]> wrote:

> I am a bit confused.
>
> It sounds like you are sniffing a bearer token from an unsecured
> connection to a resource server and then letting another client use that
> token.
>
> Is this correct?
>
> Phil
>
> @independentid
> www.independentid.com
> [email-masked]
>
>
>
>
>
> Ø  the attack you describe can be carried out against any app that uses
> the OAuth "implicit grant flow", which Facebook calls "client-side
> authentication".
>
> The main concern we raised here is not about attacking client-side apps.
> We don’t think it is a meaningful security consequence when a client-side
>> 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
>> Please kindly give us an ack when you receive this message. If you want
>> to know more details, please let us know.
>> Best Regards,

---

From: Phil Hunt <[email-masked]>
Date: Fri, 15 Jun 2012 17:55:00 -0700

Ok. Are you recommending specific changes that should be made to the group?

Phil

On 2012-06-15, at 17:30, Nat Sakimura <[email-masked]> wrote:

> But I am not sure if I should disclose the detail of the attack here in the public list as that will open up a much more serious attack vector than leaked passwords hash in recent incidents. 
> 
> OAuth is not an authentication protocol. It is an access delegation protocol. 
> The fact that one has an authorization to access an API does not mean that he is the subject. 
> There are bunch of assumptions that have to be fulfilled for OAuth to act as an entity authentication. 
> If you pass a token from a client to another, e.g., from an APP to the server side component, the assumption is violated. 
> That's why we have been creating OpenID Connect. OpenID Connect adds bunch of restrictions on OAuth 2.0. They are the things you have to do before you can use OAuth 2.0 as an authentication protocol.
> 
> Best, 
> 
> Nat
>

---

From: Nat Sakimura <[email-masked]>
Date: Sat, 16 Jun 2012 10:19:25 +0900

Hmm let me see. I was not proposing any change because OAuth as a protocol
is just fine. It is the mis-use of OAuth (i.e, using OAuth for
authentication) that is causing the problem.

In OAuth, an entity, say Alice, has given the authorization to access the
resource to people/services, say Eve.
Eve being able to access to the resource is not a problem at all.
Bob, looking at Eve being able to access the Alice's resource, mistaking
Eve as Alice is outright stupid, but that is what is happening in the
attack described.

However, after reading your message, I started to think that perhaps
warning the implementors of the above in the security consideration may be
useful. A new section 10.16? Is it not too late?

=nat

On Sat, Jun 16, 2012 at 9:55 AM, Phil Hunt <[email-masked]> wrote:

> But I am not sure if I should disclose the detail of the attack here in
> the public list as that will open up a much more serious attack vector than
>>>  This is a fairly well known (hopefully by now) issue. We, at the
>>> OpenID Foundation, call it "access_token phishing" attack these days. See:
>>> 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

---

From: nov matake <[email-masked]>
Date: Sat, 16 Jun 2012 12:22:23 +0900

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:

> 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-masked]> wrote:
> Hi Nat and Rui,
>

---

From: Kristofor Selden <[email-masked]>
Date: Sat, 16 Jun 2012 09:33:01 -0700

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 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

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Wed, 20 Jun 2012 14:03:25 +0000

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.

1)      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.

2)      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.

3)      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?

4)      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-masked] [mailto:[email-masked]] 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

FB Connect is authentication and authorization, where OAuth 2 is concerned only with authorization - I'm not sure that app developers appreciate this subtlety.

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

nov

Nat
On Sat, Jun 16, 2012 at 5:34 AM, Francisco Corella <[email-masked]<mailto:[email-masked]>> wrote:

Hi Nat and Rui,

Francisco

________________________________
From: Nat Sakimura <[email-masked]<mailto:[email-masked]>>
To: rui wang <[email-masked]<mailto:[email-masked]>>
Cc: matake nov <[email-masked]<mailto:[email-masked]>>; Yuchen Zhou <[email-masked]<mailto:[email-masked]>>; oauth <[email-masked]<mailto:[email-masked]>>; Shuo Chen (MSR) <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, June 14, 2012 1:50 PM
Subject: Re: [OAUTH-WG] Report an authentication issue

Nat
On Fri, Jun 15, 2012 at 2:18 AM, rui wang <[email-masked]<mailto:[email-masked]>> 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-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 20 Jun 2012 15:06:48 -0400

On 6/20/2012 10:03 AM, Lewis Adam-CAL022 wrote
...
>
> 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.
>
> 1)...
>
> 3)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?
>
> 4)     ...
>
Adam,

The problem is that the video server that you described, according to 
the two options needs specific authentication of the user.  OAuth was 
not designed for this purpose; it was designed for delegating access.  
In your use case,  there is no delegation. The only legitimate users are 
police officers and they "must logon to the video server in order to 
access video content."  And so the server must authenticate them. There 
is no need for OAuth in this scenario.

Igor
>
> *From:[email-masked] [mailto:[email-masked]] *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)
> 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
>
> 4. Access to https://graph.facebook.com/app?access_token=YOUR_TOKEN 
> (Facebook custom way, moreover undocumented API)
>
> 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.
>
> 1. Properly verify the signature/HMAC of the "signed_request". This 
> will essentially audience restricts the token.
>
> 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-masked] <mailto:[email-masked]>> wrote:
>
> Hi Nat and Rui,
>
>     ------------------------------------------------------------------------
>
>     *From:*Nat Sakimura <[email-masked] <mailto:[email-masked]>>
>     *To:* rui wang <[email-masked] <mailto:[email-masked]>>
>     *Cc:* matake nov <[email-masked] <mailto:[email-masked]>>; Yuchen
>     Zhou <[email-masked] <mailto:[email-masked]>>;
>     oauth <[email-masked] <mailto:[email-masked]>>; Shuo Chen (MSR)
>     <[email-masked] <mailto:[email-masked]>>
>     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
>
>     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/)
>
>     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.
>
>     Please kindly give us an ack when you receive this message. If you
>     want to know more details, please let us know.
>
>     Best Regards,
>     [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>
> [email-masked] <mailto:[email-masked]>

---

From: Justin Richer <[email-masked]>
Date: Wed, 20 Jun 2012 15:10:32 -0400

> explicitly define this?  Is there a threat in using OAuth as I describe?

You've hit on it here -- you're using OAuth *plus* a few other bits to 
accomplish this. Using a JWT lets you do things like signed tokens and 
audience restriction so that clients won't just take *any* token.

> 4)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.
>

Connect adds a few things on top of OAuth to make authentication 
possible, and one of these is the id_token. But what you're really after 
in your scenario isn't authentication at the RS per se -- it's 
authorization for accessing it.

  -- Justin

---

From: Justin Richer <[email-masked]>
Date: Wed, 20 Jun 2012 15:26:28 -0400

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 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.
>
> 1)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.
>
> 2)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.
>

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 20 Jun 2012 15:38:36 -0400

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 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.
>
> 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.
>
> 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
>
>> 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.
>>
>> password into the client, and the client sends the username / 
>> password off to the server, which authenticates it, or possibly uses 
>> HTTP digest.
>>
>> authenticates user, and OP redirects client back to the server/RP 
>> with an assertion that primary authentication was successful.
>>
>> 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?
>>
>> 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
>>
>> 2. There is an undocumented API for Facebook which returns to whom 
>> the token was issued. This also audience restricts the token.
>>
>> names in the public list, though, eventually, we would publish them 
>> in a paper.
>>
>> Nat
>>
>>     issue. Some immediately issued a patch to fix it while others
>>     have not.
>>
>>     which means the service has to cut off many users pausing
>>     business problems.
>>
>>     Nat
>>
>>     We are a research team in Microsoft Research. In January, 2011,
>>     we reported a vulnerability in Facebook Connect which allowed
>>     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.
>>
>>     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,
>>     Please kindly give us an ack when you receive this message. If
>>     you want to know more details, please let us know.
>>
>>     Best Regards,

---

From: Justin Richer <[email-masked]>
Date: Wed, 20 Jun 2012 15:59:45 -0400

That's a red herring -- the use case is that whatever the police officer 
is using needs to be authorized to access the video service, not that 
the police officer needs to "log in" necessarily. Adam has pointed out 
in another thread that the services that users use to log in are in a 
different security domain from the video servers, too -- so it's classic 
federated authorization, using a native client.

  -- Justin

On 06/20/2012 03:38 PM, Igor Faynberg wrote:
> There is no delegation here, and there is no need to use third party 
> for authentication.
>
> Igor
>
>> 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 
>>> 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 
>>> video server (RP), the server would redirect the client to the OP, 
>>> OP authenticates user, and OP redirects client back to the server/RP 
>>> 4)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
>>>
>>> concerned only with authorization -- I'm not sure that app 
>>> developers appreciate this subtlety.
>>>
>>> FB Connect, you do that, but /also/ authenticate with the app you 
>>> are authorizing.
>>>
>>> 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 
>>> unfortunately it doesn't work when using authorization codes 
>>> obtained via FB iOS SDK.
>>>
>>>     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.
>>>
>>>     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

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Wed, 20 Jun 2012 20:21:06 +0000

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-masked]",
  "aud":" https://[email-masked]",
  "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-masked] [mailto:[email-masked]] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: [email-masked]
Subject: Re: [OAUTH-WG] Report an authentication issue

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

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-masked]<mailto:[email-masked]> [mailto:[email-masked]] 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

Kris

nov

Nat

Hi Nat and Rui,

Francisco

Nat

OAuth mailing list

OAuth mailing list

---

From: Igor Faynberg <[email-masked]>
Date: Wed, 20 Jun 2012 16:50:07 -0400

Adam,

Now I think I understand the use case. I agree with you that if the 
token is made specifically out to authenticate the user, it is an 
entirely different matter.

(In the early OAuth days, I was suggesting to consider structuring a 
token simliarly to a Kerberos ticket, which is more or less what would 
serve the use case you propose.)

Igor

On 6/20/2012 4:21 PM, Lewis Adam-CAL022 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:
>
> 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 :-(
>
> Behalf Of *Igor Faynberg
> *Sent:* Wednesday, June 20, 2012 2:39 PM
> *To:* [email-masked]
> 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 
> If I wanted to use OAuth, the client would send an authorization 
> 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 
> *From:[email-masked] <mailto:[email-masked]> 
> [mailto:[email-masked]] *On Behalf Of *Kristofor Selden

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 21 Jun 2012 10:08:39 +0900

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-masked]> 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"}****
>
>   "acr":”password”}****
> ****
> ** **
> 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-masked] [mailto:[email-masked]] *On Behalf
> Of *Igor Faynberg
> *Subject:* Re: [OAUTH-WG] Report an authentication issue****
>
>  ** **
>
> 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:
>
> 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.
>
> 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.
>
>
> ****
>
> 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-masked] [mailto:[email-masked]<[email-masked]>]
> *On Behalf Of *Kristofor Selden
> *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
> 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).****
>
>  ****
>
> 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 ... ****
>
>  ****
>
> essentially audience restricts the token. ****
>
> token was issued. This also audience restricts the token. ****
>
>  ****
>
> defined in OAuth. ****
> 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****
>
> ****
> Francisco****
>  ****
> *Subject:* Re: [OAUTH-WG] Report an authentication issue****
>
>  ****
>
> ****
>  ****
> it while others have not.  ****
>
>  ****
>
> off many users pausing business problems. ****
>
>  ****
>
> Nat****
>
> On Fri, Jun 15, 2012 at 2:18 AM, rui wang <[email-masked]> wrote:**
> **
>
> Dear Facebook Security Team and OAuth Standard group,****
>
> )****
> allows an attacker to log into a victim user's account without password.**
> **
>
> same issue on another Windows 8 metro-app Givit.****
>
> to OAuth Standard group as well.****
>
> Gavit.****
> know more details, please let us know.****
>
> Best Regards,
> Yuchen Zhou, Rui Wang, and Shuo Chen****
>
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
>  ****
>
> --
> Nat Sakimura (=nat)****
>
> @_nat_en****
>  ****
> ****
> ****
>  ****
> Nat Sakimura (=nat)****
> @_nat_en****
>  ****
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>  ****
>
>
>
>
> ****
>
> _______________________________________________****
>
> OAuth mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>
>
> ****
>
> ** **
>
> ** **
>
> _______________________________________________****
>
> OAuth mailing list****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 21 Jun 2012 16:01:23 +0000

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:[email-masked]]
Sent: Wednesday, June 20, 2012 8:09 PM
To: Lewis Adam-CAL022
Cc: [email-masked]; [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Hi Igor,

  "prn":"[email-masked]<mailto:[email-masked]>",

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Igor Faynberg
Sent: Wednesday, June 20, 2012 2:39 PM
To: [email-masked]<mailto:[email-masked]>

Igor

 -- Justin

What am I still missing?
adam

Kris

nov

Nat

Hi Nat and Rui,

Francisco

Nat

OAuth mailing list

OAuth mailing list

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 21 Jun 2012 12:28:13 -0400

+1 for exploring.

Igor

On 6/21/2012 12:01 PM, Lewis Adam-CAL022 wrote:
> ...
>
> 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.
>
> *From:*Nat Sakimura [mailto:[email-masked]]
> *Sent:* Wednesday, June 20, 2012 8:09 PM
> *To:* Lewis Adam-CAL022
> *Cc:* [email-masked]; [email-masked]
>    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.
>       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-masked] 
> <mailto:[email-masked]>> wrote:
>
> Hi Igor,
>
>   "prn":"[email-masked] <mailto:[email-masked]>",
> [mailto:[email-masked] <mailto:[email-masked]>] *On 
> Behalf Of *Igor Faynberg
> *To:* [email-masked] <mailto:[email-masked]>
>
>

---

From: Phil Hunt <[email-masked]>
Date: Thu, 21 Jun 2012 09:33:05 -0700

I see elements of improper use of OAuth flows as well as improper use of bearer tokens. We have to keep it a simple comment in both specs.

As for exploration, I would support it being explored more in the next  OAuthWG charter (if it can be fit in).

Phil

@independentid
www.independentid.com
[email-masked]

On 2012-06-21, at 9:28 AM, Igor Faynberg wrote:

>> 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. 
>>  
>>  
>> 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. 
>> 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. 
>> On Thu, Jun 21, 2012 at 5:21 AM, Lewis Adam-CAL022 <[email-masked]> 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"}
>>   "acr":”password”}
>> 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 :-(
>>  
>>  
>>  
>> 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 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: Nat Sakimura <[email-masked]>
Date: Fri, 22 Jun 2012 01:37:50 +0900

I think you are way beyond what OAuth provides.

OpenID Connect probably is a better fit.
id_token was built with non-confidential client in mind.
That was in our use case from the beginning.
Supporting apps was also in our use case, and doing Holder of key was also.
With a native client, you might as well want to do HoK.
I also strongly believe that a secure native client should generate key
pairs and leverage it.

Re: your question:

> 1) identify the user, and

Use the id_token.

> 2) make authorization decisions based on what roles that user has within
the enterprise.

It depends on where the policy decision point is.
Authorization server can be the PDP, then it issues the id_token for the
APP and access token for the RS. RS will be a pure play PEP. For additional
security, the APP could present id_token together with access_token. OR use
id_token as access token. The id_token may include the public key of the
App, and the video can be encrypted using that essentially audience
restricting the video.

It could also be that RS is the PDP+PEP. Your model seem to fit this one.
Then, you just take id_token there and PDP portion of the RS gives you the
access token, which you present it to the PEP portion of the RS. In this
case, I think id_token should be audience restricted to the RS. It should
carry the public key of the APP inside it. The RS may encrypt the data
using it, so the video data is actually transmitted only to the intended
client.

Best,

Nat
On Fri, Jun 22, 2012 at 1:01 AM, Lewis Adam-CAL022 <
[email-masked]> 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:[email-masked]]
> 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. ****
>
> reasons such as: ****
>    AS-RS may be doing some proprietary thing inside it) access token. ****
>    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****
>
> ** **
>
> [email-masked]> wrote:****
>
> Hi Igor,****
>
>  ****
>
> *To:* [email-masked]****
> But this use case  does need OAuth, period:****
>
>
>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 21 Jun 2012 19:05:46 +0000

Hi Nat ...

<acl> Yes, exactly!

Then, you just take id_token there and PDP portion of the RS gives you the access token, which you present it to the PEP portion of the RS.

<acl> if by "you" you're referring to the native client, the this is EXACTLY what I want to do.

1.      User launches native client on iPhone

2.      Native client (via UA) triggers Authorization Request (response_type=id_token) to OpenID Connect provider.

3.      OpenID Connect provider authenticates user

4.      Id_token is returned to the native client via the UA in Response message

5.      Native client includes id_token in RESTful API calls to the RS

6.      RS uses subject of id_token to make authorization decision.

It seems that every time I describe this, I get a mix of responses ranging from "that's not the intended usage of the id_token" to "sounds like that should work."  This is giving me a great deal of pause.

In this case, I think id_token should be audience restricted to the RS.

<acl> absolutely!

---

From: Paul Madsen <[email-masked]>
Date: Thu, 21 Jun 2012 15:59:52 -0400

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.

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'

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).

paul

On 6/21/12 12:01 PM, Lewis Adam-CAL022 wrote:
> 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.
>

---

From: Hannes Tschofenig <[email-masked]>
Date: Fri, 22 Jun 2012 11:28:59 +0300

Hi Adam, 

It takes a document to add new functionality to Oauth. Just write one and
submit it to the group.

Ciao
Hannes

On 6/21/12 7:01 PM, "ext Lewis Adam-CAL022"
<[email-masked]> wrote:

> Hi Nat,
>  
> I¹m beginning to wonder what it would take to add a new profile of sorts to
> either OAuth or Connect.
>  
> Now the world is moving toward RESTful APIs Š and the preferred means to
> secure RESTful APIs is OAuth.
>  
> 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
> 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.
>  
>  
> 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.
> <[email-masked]> 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"}
>   "acr":²password²}
> hq4zk+ZknjggCQgZm7ea8fI79gJEsRy3E8LHDpYXWQIgZpkJN9CMLG8ENR4Nrw+n7iyzixBvKXX8P5
> 3BTCT4VghPBWhFYSt9tHWu/AtJfOTh6qaAsNdeCyG86jmtp3TDMwuL/cBUj2OtBZOQMFn7jQ9YB7kl
> Iz3RqVL+wNmeWI4=
>  
> 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 :-(
>  
>  
>  
> 
> 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.
> 
> 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:
> 
> 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.
> 
> 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
> 
> here.
> 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
> 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
> that this access token (let¹s assume it¹s a JWT) would contain the user¹s
> 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
>  
>  
> 
> 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.
> 
>  
> 
> 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?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
>  
> 
> unfortunately it doesn't work when using authorization codes obtained via FB
> iOS SDK.
> 
> 2. There is an undocumented API for Facebook which returns to whom the token
> was issued. This also audience restricts the token.
> 
>  
> 
>> Cc: matake nov <[email-masked]>; Yuchen Zhou <[email-masked]>; oauth
>> <[email-masked]>; Shuo Chen (MSR) <[email-masked]>
>> 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.  
>> 
>>  
>> 
>> 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
>> 
>> We are a research team in Microsoft Research. In January, 2011, we reported a
>> vulnerability in Facebook Connect which allowed everyone to sign into
>> after reporting.
>> 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.
>> 
>> (https://developers.facebook.com/docs/mobile/android/build/#sdk) seems to
>> 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.
>>

---

From: Chuck Mortimore <[email-masked]>
Date: Fri, 22 Jun 2012 08:15:02 -0700

I'm not convinced a new document is required.   This is basically describing how out OAuth deployment works, with the exception that our token format is opaque.

Nothing seems new.

- cmort

On Jun 22, 2012, at 1:29 AM, "Hannes Tschofenig" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Adam,

It takes a document to add new functionality to Oauth. Just write one and submit it to the group.

Ciao
Hannes

On 6/21/12 7:01 PM, "ext Lewis Adam-CAL022" <[email-masked]> wrote:

Hi Nat,

I’m beginning to wonder what it would take to add a new profile of sorts to either OAuth or Connect.

Now the world is moving toward RESTful APIs … and the preferred means to secure RESTful APIs is OAuth.

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).

Best,

Nat

Hi Igor,

Igor

 -- Justin

What am I still missing?
adam

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

nov

Nat

Hi Nat and Rui,

Francisco

Nat

Best Regards,

---

From: prateek mishra <[email-masked]>
Date: Fri, 22 Jun 2012 17:11:13 -0400

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

>     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.

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sat, 23 Jun 2012 18:52:22 +0200

Hi Adam,

let me explain why I don't see a need for a new profile.

As far as I understand your scenario, you want to give users from 
different security domains access to the same RS.

I see two ways to handle this without any need to extend OAuth:

1) multiple AS (also performing authentication)

You already mentioned this option. Every department runs its AS, which 
authenticates and authorizes access to the RS for the particular 
officer. As a pre-requisite, RS and ASs must use the same token design 
(self-contained vs. handle-based), token format (e.g. SAML or JWT) and 
the RS must _rely_ multiple ASs. This will be possible to implement with 
the drafts under consideration (namely JWT), but I consider this a 
substantial restrictions on the design of the RS!

2) single AS relying on multiple IDPs for authenticaton

The alternative is to let a dedicated AS issue the tokens for the 
central RS. This AS uses the IDPs of the different security domain for 
the purpose of authenticating the officers (e.g. using SAML or OpenID). 
The difference is that the RS only trusts this single AS, which is 
easier to implement because it is a nearly private relationship.

best regards,
Torsten.

---

From: Nat Sakimura <[email-masked]>
Date: Sun, 24 Jun 2012 22:29:17 +0900

On Fri, Jun 22, 2012 at 4:59 AM, Paul Madsen <[email-masked]> 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.

> obtained by the API/RS by sending the tokens for 'validation' or

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.

> *From:* Nat Sakimura [mailto:[email-masked] <[email-masked]>]
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Mon, 25 Jun 2012 16:54:45 +0000

Okay :-)

I've gotten lot of feedback ... consider a few snippets below, all part of this thread and in response to my question:

Igor said: OAuth was not designed for this purpose; it was designed for delegating access.  In your use case,  there is no delegation. The only legitimate users are police officers and they "must logon to the video server in order to access video content."  And so the server must authenticate them. There is no need for OAuth in this scenario.

Nat said: Yes, OAuth can be profiled to enable authentication. In fact, initial draft of OpenID Connect was just like you described.

Phil said: I see elements of improper use of OAuth flows as well as improper use of bearer tokens. We have to keep it a simple comment in both specs.

Nat said: "I think you are way beyond what OAuth provides."

Paul said: 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. ... 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).

Chuck said: This is basically describing how our OAuth deployment works, with the exception that our token format is opaque.

Patreek said: 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.

I think the above just really drives home the fact that if OAuth is to be used for securing enterprise API calls in a post-SOAP world, something needs to be stated more explicitly.  OAuth was not designed to provide authentication of the user to the RS.  But it seems we all agree that it can be profiled to do so.  Connect is supposed to address authentication, but only from the view of the client, and not the RS.  Only the access token goes to the RS, so if we want to authenticate a user to the RS, then we're back to OAuth, since Connect doesn't intend to send the id_token to the RS.  Nat mentioned that it "could," but I haven't seen that as part of the Connect specs thus far.

There is *clearly* confusion around whether OAuth is to be used as authentication or not, and I think this thread has shown that.  If I'm going to deploy OAuth for Authentication, then I really need a spec to point to (when my customers ask) that says it can be used that way, especially with all the "OAuth is NOT authentication" blog posts floating around in cyberspace these days.

I'm thinking two things:

1)      it would at least be worthwhile to document this use case, and maybe the OAuth use cases draft would be a good place to capture it.

2)      maybe a stand alone, informational draft would also be a good idea, especially if we all agree that it's only a profile of OAuth, and does not require any technical changes to the core draft.  Something that talks outright about an enterprise-centric world, rather than the user RO-centric world that OAuth was really written around.  This might give future generation of Enterprise folks like myself an easier time.

Thoughts?
-adam

From: Nat Sakimura [mailto:[email-masked]]
Sent: Sunday, June 24, 2012 8:29 AM
To: Paul Madsen
Cc: Lewis Adam-CAL022; [email-masked]
Subject: Re: [OAUTH-WG] Report an authentication issue

On Fri, Jun 22, 2012 at 4:59 AM, Paul Madsen <[email-masked]<mailto:[email-masked]>> 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).

paul

From: Nat Sakimura [mailto:[email-masked]]
Sent: Wednesday, June 20, 2012 8:09 PM
To: Lewis Adam-CAL022
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Report an authentication issue

Best,

Nat

Igor

 -- Justin

What am I still missing?
adam

Kris

nov

Nat

Francisco

Nat

OAuth mailing list

OAuth mailing list

OAuth mailing list

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Mon, 25 Jun 2012 18:31:01 +0000

Hi Torsten,

Your option #2 below is the model I was first attracted to.  The architecture as you mention is clean.  But the need to run multiple round trips (one to get the SAML assertion, another to get the access token), plus the inherently large size of a SAML assertion (compared to an unstructured access token, or even a JWT), was producing too much latency.

Hence I have moved my interest to option #1.  I think the easiest thing to do is have the user authenticate to the local AS, get in return a structured JWT access token (which will look a lot like the Connect id_token) and present that JWT access token to the RS in the different domain, and that RS will use that JWT access token to authenticate the user.  Ideally I would like to use the id_token from Connect, but I'm getting push back on that idea since the id_token has really been profiled for the client, not the RS.

-adam

From: Torsten Lodderstedt [mailto:[email-masked]]
Sent: Saturday, June 23, 2012 11:52 AM
To: Lewis Adam-CAL022
Cc: Nat Sakimura; [email-masked]
Subject: Re: [OAUTH-WG] Report an authentication issue

Hi Adam,

As far as I understand your scenario, you want to give users from different security domains access to the same RS.

You already mentioned this option. Every department runs its AS, which authenticates and authorizes access to the RS for the particular officer. As a pre-requisite, RS and ASs must use the same token design (self-contained vs. handle-based), token format (e.g. SAML or JWT) and the RS must _rely_ multiple ASs. This will be possible to implement with the drafts under consideration (namely JWT), but I consider this a substantial restrictions on the design of the RS!

The alternative is to let a dedicated AS issue the tokens for the central RS. This AS uses the IDPs of the different security domain for the purpose of authenticating the officers (e.g. using SAML or OpenID). The difference is that the RS only trusts this single AS, which is easier to implement because it is a nearly private relationship.

best regards,
Torsten.

Best,

Nat

Igor

 -- Justin

What am I still missing?
adam

Kris

nov

Nat

Hi Nat and Rui,

Francisco

Nat

OAuth mailing list

OAuth mailing list

OAuth mailing list

---

From: Igor Faynberg <[email-masked]>
Date: Mon, 25 Jun 2012 14:34:41 -0400

Well, actually Igor missed a larger context when he said that. But when  
this context was pointed out to him, he humbly stood corrected and 
expressed interest in addressing this matter in OAuth!

Igor

On 6/25/2012 12:54 PM, Lewis Adam-CAL022 wrote:
>
> Okay :-)
>
> I've gotten lot of feedback ... consider a few snippets below, all 
> part of this thread and in response to my question:
>
> *Igor said*: OAuth was not designed for this purpose; it was designed 
> for delegating access.  In your use case,  there is no delegation. The 
> only legitimate users are police officers and they "must logon to the 
> video server in order to access video content."  And so the server 
> must authenticate them. There is no need for OAuth in this scenario.
>
> ...

---

From: Nat Sakimura <[email-masked]>
Date: Thu, 28 Jun 2012 12:33:58 +0900

On Tue, Jun 26, 2012 at 1:54 AM, Lewis Adam-CAL022 <
[email-masked]> wrote:
[...snip...]

> ** **
>
> I think the above just really drives home the fact that if OAuth is to be
> used for securing enterprise API calls in a post-SOAP world, something
> needs to be stated more explicitly.  OAuth was not designed to provide
> authentication of the user to the RS.  But it seems we all agree that it
> can be profiled to do so.  Connect is supposed to address authentication,
> but only from the view of the client, and not the RS.  Only the access
> token goes to the RS, so if we want to authenticate a user to the RS, then
> we’re back to OAuth, since Connect doesn’t intend to send the id_token to
> the RS.  Nat mentioned that it “could,” but I haven’t seen that as part of
> the Connect specs thus far.  ****
>
> ** **
>
> There is **clearly** confusion around whether OAuth is to be used as
> authentication or not, and I think this
>
thread has shown that.  If I’m going to deploy OAuth for Authentication,
> then I really need a spec to point to (when my customers ask) that says it
> can be used that way, especially with all the “OAuth is NOT authentication”
> blog posts floating around in cyberspace these days.
>

Confusion is true. The fact is that OAuth by itself is incapable of
providing user authentication result to the resource server (nor the client
for that matter). It in fact is completely out of scope. OAuth is an access
delegation (aka authorization) mechanism. It has nothing to say about who
uses the token. Assuming the user of the access token is the resource owner
is a false assumption.

> ****
>
> ** **
>
> I’m thinking two things: ****
>
> **1)      **it would at least be worthwhile to document this use case,
> and maybe the OAuth use cases draft would be a good place to capture it.
>
Starting from a stand alone use case would be good.
My impression (I may be wrong) is that your requirement is to be able to

(1) Log the user identifier of the person who is accessing the resource at
the resource server for the audit etc. purposes.
(2) Do the holder of the key so that the RS is sure that the person
accessing with the access token
     is really the person.
(3) In addition, the RS may not be able to talk to AS directly.
     [Well, this is one of my use case anyways.]
(4) In some cases, the client may not be able to communicate with AS
directly at the time of RS access. [ditto]

Are these correct?

FYI, (2) has been a work item for John Bradley for sometime.
For (1), (3), (4), OIDF's CX working group has been working on it.
The Working Group currently is dormant waiting for the Connect to finish
so that it can leverage it. (Good portion of Connect actually came from CX
work results.)

****
>
> **2)      **maybe a stand alone, informational draft would also be a good
> idea, especially if we all agree that it’s only a profile of OAuth, and
> does not require any technical changes to the core draft.  Something that
> talks outright about an enterprise-centric world, rather than the user
> RO-centric world that OAuth was really written around.  This might give
> future generation of Enterprise folks like myself an easier time.
>
That's essentially what we are doing with OpenID Connect, though not
informational document but as a normative standard at OIDF.

Best,

Nat

> Thoughts?****

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 28 Jun 2012 20:13:12 +0000

Hi Nat,

Starting from a standalone use case would be good.
My impression (I may be wrong) is that your requirement is to be able to

(1) Log the user identifier of the person who is accessing the resource at the resource server for the audit etc. purposes.

<acl> yes ... that *and* to authenticate the user in the first place.  So again, my access_token will actually look like the Connect id_token.  I would even prefer to use the id_token, except that it violate the spirit of Connect to pass the id_token to the RS (e.g. it was only meant for consumption by the client).

My problem space can be distilled to something very simple.

-          We come from a SOAP API world where we use WS-Trust to secure the SOAP API calls.  WS-Trust makes it very simple for a WS-* client to collect the user's primary credentials, exchange it for a (SAML) bearer token via the STS, and embed that bearer token in SOAP-based API calls to the WS-* server. This is most definitely *authentication*

-          We are moving to a RESTful API world.  I just want to be able to do the same thing as above. How do I enable my REST-based client to collect the user's password, exchange it for a (JWT) bearer token via the STS, and embed that bearer token in RESTful API calls to the REST-based server, such that the REST-based server can *authenticate* the client?

(2) Do the holder of the key so that the RS is sure that the person accessing with the access token
     is really the person.

<acl> that would be nice, but most of my users will be using passwords in the beginning, so this is not an option.  I'm using the literal definition of bearer token here, taken straight out of the OAuth bearer token spec, e.g. "Any party in possession of a bearer token (a "bearer") can use it to get
access to the associated resources (without demonstrating possession of a cryptographic key)."

<acl> Right ... this is why I am now looking at structured JWTs.

(4) In some cases, the client may not be able to communicate with AS directly at the time of RS access. [ditto]

<acl> Right again, we have disaster scenarios to think about where the AS might not be reachable.  but this is a use case for next steps.  Trying to walk before we fly here :-)

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Jun 2012 16:47:54 -0400

Adam,

This is getting tangled up in semantics.

The AS authenticates the user and Authorizes the client (native App) to access the protected resource (video server) via issuing it a access token, or a authorization code that it can trade at a token endpoint for a refresh_token and access_token.

At that point the client has no notion of who the user is unless a openID Connect id_token was also sent.  I suspect that the video player app may not care who the person, only what it can access.

The App then uses its access token to prove that it was delegated access to the server by some person (Resource owner in OAuth speak).  
In your STS example you call this Authentication, but in OAuth it is Authorization.  The client is the one being authenticated to the resource via the token.
The User is Authenticated to the AS.   The same trust chain exists it just uses different terms.

That token can be structured like the id_token is, but there is an important difference.  The access token's audience is the resource server and the id_token's audience is the client.
That is one of the reasons they are separate.

This looks like a relatively strait forward OAuth use case to me,  you can probably also use opaque tokens with a AS STS and some caching logic at the RS if you want to keep the token size down.

John B.

On 2012-06-28, at 4:13 PM, Lewis Adam-CAL022 wrote:

> <acl> yes … that *and* to authenticate the user in the first place.  So again, my access_token will actually look like the Connect id_token.  I would even prefer to use the id_token, except that it violate the spirit of Connect to pass the id_token to the RS (e.g. it was only meant for consumption by the client).
>  
> -          We come from a SOAP API world where we use WS-Trust to secure the SOAP API calls.  WS-Trust makes it very simple for a WS-* client to collect the user’s primary credentials, exchange it for a (SAML) bearer token via the STS, and embed that bearer token in SOAP-based API calls to the WS-* server. This is most definitely *authentication*
> 
> -          We are moving to a RESTful API world.  I just want to be able to do the same thing as above. How do I enable my REST-based client to collect the user’s password, exchange it for a (JWT) bearer token via the STS, and embed that bearer token in RESTful API calls to the REST-based server, such that the REST-based server can *authenticate* the client?  
> 
> <acl> that would be nice, but most of my users will be using passwords in the beginning, so this is not an option.  I’m using the literal definition of bearer token here, taken straight out of the OAuth bearer token spec, e.g. “Any party in possession of a bearer token (a "bearer") can use it to get
> access to the associated resources (without demonstrating possession of a cryptographic key).”
>  
> <acl> Right … this is why I am now looking at structured JWTs.
>

---

From: Lewis Adam-CAL022 <[email-masked]>
Date: Thu, 28 Jun 2012 22:34:58 +0000

Hi John,

It may be semantics, but in my use cases, the AS is not "authorizing" anything.  It's 1) authenticating the user, and 2) issuing a structured JWT access_token which contains claims about the user (again, just like the id_token, but as you said, aud=RS).

The video client on the iPhone/Android uses this as a bearer token, and includes it an a request to the video server.  The video server uses the claims in the JWT access_token to authenticate the user, and then makes its own authorization decisions (e.g. maps user id to app-centric roles, etc.)

If you still feel this is within the spirit of OAuth, then great :-)

My concern is still that one of our customer's will read your blog and fire back at us ... "but John says OAuth is not for authentication"  ;)

This is why I would like to explore the idea of putting out an informational draft profiling OAuth for authentication, since everybody seems to at least agree that it can be profiled to do so.

Tx!
adam

From: John Bradley [mailto:[email-masked]]
Sent: Thursday, June 28, 2012 3:48 PM
To: Lewis Adam-CAL022
Cc: Nat Sakimura; [email-masked]
Subject: Re: [OAUTH-WG] Report an authentication issue

Adam,

John B.

Hi Nat,

---

From: John Bradley <[email-masked]>
Date: Thu, 28 Jun 2012 19:43:47 -0400

Hi Adam,

I am working on an additional security concern around Authentication for the spec.

The OAuth spec is about protecting the "Protected Resource" in your case a video server.  
That is exactly what OAuth is intended to do.

The reason the term authorization is used is that the client can be a 3rd party web service,  a native app, or a JavaScript client in a user Agent.

In the case of the user granting a 3rd party service access to the video server via the same OAuth mechanism you probably would not say that the video server is authenticating the user as the user may well not be present.   The protected resource is validating that the 3rd party service has been delegated access by the user (resource owner) via the authorization server.

In the case where you have a client that by design is running on a device that is controlled by a single person and the person is authenticating themselves to the authorization server and granting the app access to the resource, you have crated a greatly constrained profile that is effectively the same as Authentication of the device holder to the resource.   You are however doing that by using a authorization mechanism and leveraging the constraints of your profile.

There are however places you can get into trouble if you don't have the correct profile and environment.

The Authentication that openID Connect, Facebook and others are doing is Authentication of the user to the client.   You see this in a native App like foursquare.

In that case I use Facebook's Authorization server (same apples to twitter) to identify myself to the app and give it access to push notifications.
I Authorize the App to access the Facebook graph API so it can get my name and other information, so In some sense I have Authenticated to it, and am logged in.
That is all well and good.

The problem comes in when the App passes the access token back to it's own servers and they assume that I am logged into the app and can let it post location information and get location history.
This all works perfectly fine, on the face of it.

The problem is that I also grant other clients access to my Facebook graph API and they have valid access tokens to get my information.

Any one of those sites that have access_tokens for my account can pass that to foursquare over the API they have for their client and get my information at foursquare.
(I believe forsquare is now using a proprietary Facebook API to validate that the token was issued to it's client_id to stop this attack now.)

All public clients are susceptible to this not just Apps.

The OAuth model works for you because you are using it the correct way to protect the resource.

Once you start using OAuth in ways not anticipated by the core spec, you need to consider the new attack surface.
Authenticating to the client is NOT safe with all of the flows unless additional security mechanisms are in place like the openID Connect id_token,  or facebooks introspection endpoint,
or facebooks's signed_request.   

There are ways that OAuth can be used safely for Authentication to the client but it requires profiling and extension.

My concern is that inexperienced people not use OAuth to create simple SSO flows with public clients, that are insecure for that purpose.

So Adam the bottom line is you are good to go because you are using OAuth as it is intended to be used.
You can call it Authentication if you like, but that authentication is based on a constrained profile of OAuth and tokens. It is a subset of the general Authorization mechanism.
While using JWT tokens brought to you by OpenID Connect may work as access tokens,  I don't see needing id_tokens or user_info endpoints.
There may be other applications that you develop in the future that might need them.

I hope that helps.
John B.

On 2012-06-28, at 6:34 PM, Lewis Adam-CAL022 wrote:

> Hi John,
>  
> It may be semantics, but in my use cases, the AS is not “authorizing” anything.  It’s 1) authenticating the user, and 2) issuing a structured JWT access_token which contains claims about the user (again, just like the id_token, but as you said, aud=RS). 
>  
> My concern is still that one of our customer’s will read your blog and fire back at us … “but John says OAuth is not for authentication”  ;)
>

---

From: Antonio Sanso <[email-masked]>
Date: Fri, 29 Jun 2012 17:53:14 +0100

Hi John

On Jun 29, 2012, at 1:43 AM, John Bradley wrote:

> Authenticating to the client is NOT safe with all of the flows

you are perfectly right here. At the begin of this discussion and reading your blog post I was under the impression that this "attack" was tight to the use of the implicit grant flaw.
But this is not actually the case as I could reproduce the same scenario against a client using the Authorization Code flaw.

Regards

Antonio

---

From: Justin Richer <[email-masked]>
Date: Fri, 29 Jun 2012 13:23:59 -0400

It's all about how you can swipe a token and inject it into another 
application. It's easier to trap and inject a token in the implicit flow 
because it's exposed to the user agent and there's no client secret tied 
to the token's issuance. To get the same trick to work with the code 
flow on server-based confidential clients, you'd need to inject your 
rogue token into the client's configuration or state. With the implicit 
flow and on devices, it's a bit easier just because the parts of the 
system that need access to the token are more accessible.

  -- Justin

---

From: John Bradley <[email-masked]>
Date: Fri, 29 Jun 2012 14:06:44 -0400

It is nice to know that I may occasionally be correct:)

For Server based confidential clients the risks are quite minimal as Justin points out.   There are likely other more interesting things you could do if you already have the ability to run arbitrary code on the server.

No matter what flow or client you are using, passing the access token from that client to some other server as a method of authentication is not a good idea unless you have some way to guarantee that it is a legitimate client that hasn't been compromised.   Creating a fake App with a stolen client ID is trivial.   So passing access tokens as a proxy for authentication between unauthenticated apps is a recopy for disaster.
It sort of falls under the category of bad things that can happen if you just make up new flows for tokens that are not in the spec.

Where it gets a bit grey is public clients using the code flow.  
If you look at Sec 3.2.1 only confidential clients Must Authenticate to the token endpoint.

A public client like a native app:
A public client that was not issued a client password MAY use the
   "client_id" request parameter to identify itself when sending
   requests to the token endpoint (e.g. for the purpose of providing
   end-user context, client usage statistics).

While you may assume that it is reasonable for a client with a code to make a request to the token endpoint including it's client_id and the server to only give out the access token if the client_id in the token request matches the one in the original authorization request.   However the spec specifically doesn't require that.

I think that it has to do with the precept of threat.

If you are simply using OAuth strictly for Authorization then it would make mo sense for an attacker who gets a valid code to not use it directly to access the protected resource.

However if you can escalate the codes privilege by impersonating the resource owner at a legitimate public client then an attacker might do it to get into another system.

So if the public client is perhaps vulnerable.  Now I can't imagine someone running a public client on a web server, but this would be a good reason not to.  
In general the public client would be a native app, and not easy to inject a stolen code into.

I don't have a explanation as to why public clients using the code flow are not minimally identified via their client_id.  
I suspect most implementations are doing that if they have public clients using the code flow, but I have not tested that theory.

So the code flow is safer but there are some things you need to be careful of with any public client.

John B.

On 2012-06-29, at 1:23 PM, Justin Richer wrote:

> It's all about how you can swipe a token and inject it into another application. It's easier to trap and inject a token in the implicit flow because it's exposed to the user agent and there's no client secret tied to the token's issuance. To get the same trick to work with the code flow on server-based confidential clients, you'd need to inject your rogue token into the client's configuration or state. With the implicit flow and on devices, it's a bit easier just because the parts of the system that need access to the token are more accessible.
> 
> -- Justin
>

---

From: Dick Hardt <[email-masked]>
Date: Fri, 29 Jun 2012 11:14:09 -0700

> It is nice to know that I may occasionally be correct:)

You must be delighted when it happens! ;)

> While you may assume that it is reasonable for a client with a code to make a request to the token endpoint including it's client_id and the server to only give out the access token if the client_i…

I think that is an error in the spec and should be changed, or text adding saying that the client_id SHOULD be checked.

-- Dick

---

From: Mike Jones <[email-masked]>
Date: Fri, 29 Jun 2012 18:19:20 +0000

+1 to Dick's suggestion

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dick Hardt
Sent: Friday, June 29, 2012 11:14 AM
To: John Bradley
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Report an authentication issue

-- Dick

---

From: Phil Hunt <[email-masked]>
Date: Fri, 29 Jun 2012 11:22:42 -0700

I'm not clear whether the MS Security Researcher hack was with the authorization code or the access token. If the latter, the client_id is out of the picture isn't it?

Phil

@independentid
www.independentid.com
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Fri, 29 Jun 2012 14:25:12 -0400

I agree, If there is no good reason for the token endpoint not to check the client_id with public clients then we should add that it SHOULD or MUST be checked for authorization_code and refresh_token grant_type.

Though I don't know if we want to get carried away with the whole agreeing thing.

John B.

---

From: John Bradley <[email-masked]>
Date: Fri, 29 Jun 2012 14:30:59 -0400

I think they only exploited the implicit flow.   

My point was that there is a way you could do the same thing with code if it is a public client that is not authenticating to the token endpoint.

In general making identity assumptions in the client based on a code or access_token has risks that are out of scope for OAuth.

We do however want to provide good advice about specific things that can leave systems insecure when using OAuth.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 29 Jun 2012 11:53:25 -0700

I'm not seeing how client id helps if a proxy server is somehow involved with inserting the bearer token as the researchers suggested. 

Phil

---

From: John Bradley <[email-masked]>
Date: Fri, 29 Jun 2012 15:16:25 -0400

The same thing can be done with code.

If the token endpoint checks the client_id before giving out the access token then the attack on code can be prevented, as the token endpoint won't return the access token.

The spec dosen't require authenticating public clients currently so it is a slightly more difficult attack but possible.

Dick and I are suggesting closing the hole at the token endpoint so that nether confidential nor public clients using the code flow are susceptible to this substitution attack.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 29 Jun 2012 12:29:24 -0700

We need more info on the inject method the researchers used before we can account for it. 

Phil

---

From: Dick Hardt <[email-masked]>
Date: Fri, 29 Jun 2012 12:38:04 -0700

If an attacked can modify the communications over TLS between the client and the authorization server, then I think there are many other options open to the attacker.

-- Dick

---

From: John Bradley <[email-masked]>
Date: Fri, 29 Jun 2012 16:00:42 -0400

The attack requires a web browser that allows modifying the value of the of the redirect URI.   It is dead simple cut token or code from the string and paste in the token or code that was granted by the user you want to impersonate.

OAuth responses are not signed or audience restricted to the client(except confidential clients using the code flow).  

In cases where the code or token is passed over a back channel to a server, faking the entire client is the easiest thing for the attacker.

I don't consider these to be authorization attacks,  rather attacks on a client that is inappropariatly making unwarranted assumptions about the presenter of the token.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 29 Jun 2012 13:16:03 -0700

John,

I think that helps to clarify the authorize issue.

But they were talking about a phishing site obtaining a legit access token from Facebook.
> 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 acc…

Important: the attack works because the researchers had control of the client application.  And thus they were able to insert the token between the metro client app and the server because they are able to get in the communications path. All bets are off. If the attacker can insert a token then can insert appropriate client_id's and responses in the stream as well.

Phil

@independentid
www.independentid.com
[email-masked]

---

From: John Bradley <[email-masked]>
Date: Fri, 29 Jun 2012 16:54:29 -0400

No,

Trying to explain this over email is a challenge:)

This apples to both native apps and Web Servers who are OAuth Clients.

Imagine there are two web servers that authenticate people with Facebook Connect (just an example).

Site A is I love Puppies   (An evil site)
Site B is I Hate Larry Ellison  (A good site)

You as a chocolate lover go to Site A and login to get some cool free screensaver of Puppies.
Site A gets a token for your social graph no big deal mostly public stuff.  However they discovery you work for Mr Evil who they think is purchasing paradise to put up a parking lot.

They then go to site B who is using the implicit flow for Facebook authentication.  They login using a web browser but using any one of a number of browser plugins modify the response to have the access_token that they got from you when you logged into their site.   They now post as you telling everyone that Larry can't sail and has bad fashion sense. (Perhaps true)  You might now have some explaining to do!

It would be worse if Site B had some PII about you or could transfer the money from your bank based on that authentication.

The same thing could happen with the code flow if the client is public and doesn't have a secret.   Site A doesn't use the code themselves when you login,  they just let you through to get the puppy photos.

They immediately take the token to site B and paste it into a legitimate response (note the client_id is not in the response or code ) the public client then presents that to the token endpoint with it's client_id to get the access_token.   The token endpoint just hands it over because without a client_secret it is not required to authenticate the client.

What Dick and I are saying is that we don't see the need not to verify the client_id in the request to the token endpoint.  If it were required clients would not be able to mistakenly accept codes issued to diffrent clients.

I strongly suspect most implementations do that already, so why not clarify the spec on that point.   

That won't stop the attack on implicit clients.

This is why openID 2.0, openID Connect, SAML and every other identity protocol I can think of audience restrict the assertion to the intended recipient and sign or integrity protect the response.

That is not needed for the typical authorization use case of OAuth, but is a really good idea if you are asserting Authentication information to the client.

No puppies were hurt in the creation of this message.
John B.

---

From: Phil Hunt <[email-masked]>
Date: Fri, 29 Jun 2012 16:31:22 -0700

See below...

Phil

@independentid
www.independentid.com
[email-masked]

> Site A gets a token for your social graph no big deal mostly public stuff.  However they discovery you work for Mr Evil who they think is purchasing paradise to put up a parking lot.

Ummm....ok. I didn't want to go political on this. ;-)
> They then go to site B who is using the implicit flow for Facebook authentication.  They login using a web browser but using any one of a number of browser plugins modify the response to have the a…

Soooo...according to the specs, there are now TWO mistakes:

1. Implicit is intended ONLY for java script clients in the browser. Implicit clients shouldn't have any data of value (at least retained data). 

2. The MS example states that they have control of the client application and its communications.

Do we need to make #1 even more clearer -- an entire paragraph in all caps maybe? ;-)

Since the researchers put a proxy server in between the app and Facebook. Therefore ANY OAUTH flow would be compromised since they are able to insert tokens into the flow.  Adding client id isn't going to help (so I agree with you there).

But I point out this hack only works if you can intercept the communications path.

If we were talking about some sports network on a public internet site, this problem wouldn't come up unless that hackers have access to the web sites physical network and can reconfigure the clients proxy server settings.

In the end, I don't think this is a valid *oauth* security issue since the assumption is a compromised client and/or communications path. This is a network security issue.

> The same thing could happen with the code flow if the client is public and doesn't have a secret.   Site A doesn't use the code themselves when you login,  they just let you through to get the pupp…
Agreed.

---

From: John Bradley <[email-masked]>
Date: Fri, 29 Jun 2012 23:34:42 -0400

Phil,  

You know not everyone gets a personalized example:)

In the below examples there is no proxy or other compromise of the client required only the ability to do what appears to be a SSO login using OAuth.
The attacker needs only a web browser.

When they tales about compromised clients,  they are not talking about needing to compromise the app on the users phone.

They can compromise a client on there platform e.g. load it into a iPhone emulator, or just create a new client that emulates the backend API.

There are already script kits to exploit this.   The vulnerability was distributed in API kits from Faceboo, Apple and others.

If it was just one developer getting it wrong that would be one thing,  hundreds getting it wrong by using the API in trusted development kits is a much worse problem in my opinion.

My hope is to at least make it clear to the library authors and tool venders, what are unsafe patterns.

This exploit is unfortunately not hypothetical.

John B.

---

From: Phil Hunt <[email-masked]>
Date: Sat, 30 Jun 2012 01:11:12 -0700

John,

Thanks. I am not understanding yet. But if you believe there is a problem that is enough for me. I do not mean in any way dismiss it.

Do you think the issue you described is different from the original message that started this thread? It seems so to me.  

Phil

---

From: John Bradley <[email-masked]>
Date: Sat, 30 Jun 2012 13:46:15 -0400

There is one Core issue. 
Audience restriction of the grant for the client.   This is mostly important where the client is inferring from the grant what the identity of the presenter is.

This surfaces in slightly different ways depending on the use case.

1, Native apps passing a access token over a back channel API to Authenticate the user of the App.  This is not a OAuth flow itself but is enabled by OAuth.
2, Web Applications using implicit flow.  (there are mitigations but they are not part of OAuth core) 
3, Public clients using code flow.

Bearer tokens & MAC with per token secrets are both vulnerable to this.

One observation from the security concern text I proposed that Dick and others received was that 3 could be fixed relatively simply in the spec.

The first two are out of scope for OAuth core and can really only be dealt with by documenting them as a security concern so that people avoid doing those things without additional security like using token introspection etc.

So they are all just different attacks exploiting the same flaw.

The MS researchers may have a different opinion, but I have yet to hear it.

John B.