Hi *,
On Jun 30, 2012, at 7:46 PM, John Bradley wrote:
> 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 de
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 ov
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
On 2012-06-29, at 20:34,
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, th
See below...
Phil
@independentid
www.independentid.com
phil.h...@oracle.com
On 2012-06-29, at 1:54 PM, John Bradley wrote:
> 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
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 Ell
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 Fac
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 cl
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
On Jun 29, 2012, at 11:53 AM, Phil Hunt wrote:
> I'm not seeing how client id helps if a proxy server is somehow involv
We need more info on the inject method the researchers used before we can
account for it.
Phil
On 2012-06-29, at 12:16, John Bradley wrote:
> 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
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
slightl
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
On 2012-06-29, at 11:30, John Bradley wrote:
> I think they only exploited the implicit flow.
>
> My point was that there is a way you could do the s
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
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.
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
phil.h...@oracle.com
On 2012-06-29, at 11:14 AM, Dick Hardt wrote:
>
> On Jun
+1 to Dick's suggestion
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dick
Hardt
Sent: Friday, June 29, 2012 11:14 AM
To: John Bradley
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authentication issue
On Jun 29, 2012, at 11:
On Jun 29, 2012, at 11:06 AM, John Bradley wrote:
> 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
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
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 serv
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
...@ve7jtb.com]
> Sent: Thursday, June 28, 2012 3:48 PM
> To: Lewis Adam-CAL022
> Cc: Nat Sakimura; oauth@ietf.org
> Subject: Re: [OAUTH-WG] Report an authentication issue
>
> Adam,
>
> This is getting tangled up in semantics.
>
> The AS authenticates the user an
nal
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:ve7...@ve7jtb.com]
Sent: Thursday, June 28, 2012 3:48 PM
To: Lewis Adam-CAL022
Cc: Nat Sakimura; oauth@ietf.org
Subject: Re: [OAUTH-WG] Report an authen
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.
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.
yes ... that *and* to authenticate the
On Tue, Jun 26, 2012 at 1:54 AM, Lewis Adam-CAL022 <
adam.le...@motorolasolutions.com> 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 explic
okens to do the same
between your local AS (== IDP) and the central AS.
regards,
Torsten.
>
>-adam
>
>From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
>Sent: Saturday, June 23, 2012 11:52 AM
>To: Lewis Adam-CAL022
>Cc: Nat Sakimura; oauth@ietf.org
>Subject: R
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 ... co
Hi Nat ...
It could also be that RS is the PDP+PEP. Your model seem to fit this one.
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.
if by "you" you're referring to the native client, th
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 :-(
>
> ** **
>
> ** **
>
> ** **
>
> *Fro
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: oauth-boun...@i
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
for OAuth in this scenario.
Igor
*From:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *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
kens, it's just
OAuth again.
What am I still missing?
adam
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] 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 aut
t 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
>> To:
tion/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?
>
> Fr
ix 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.
>>>
>
y 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 th
ook.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
en
>Zhou ; oauth ; Shuo Chen (MSR)
>
>Sent: Friday, June 15, 2012 3:06 PM
>Subject: Re: [OAUTH-WG] Report an authentication issue
>
>
>Hi, Francisco
>
>Thank you for your reply. Here is our response for your questions.
>
>Ø the attack you describe can be carried o
ability 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
> *To:* rui wang
> *Cc:* matake nov ; Yuchen Zhou ;
> oauth ; Shuo Chen (MSR)
> *Sent:* Thursday, June 14, 20
nt: Friday, June 15, 2012 3:59 PM
> To: rui wang
> Cc: Francisco Corella; matake nov; Yuchen Zhou; oauth; Shuo Chen (MSR)
> Subject: Re: [OAUTH-WG] Report an authentication issue
>
> I am a bit confused.
>
> It sounds like you are sniffing a bearer token from an unsecured
ent-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. Y
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
> *To:* rui wang
> *Cc:* matake nov ; Yuchen Z
Shuo Chen (MSR)
>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: h
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
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
46 matches
Mail list logo
