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?a
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
Ok. Are you recommending specific changes that should be made to the group?
Phil
On 2012-06-15, at 17:30, Nat Sakimura wrote:
> 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 w
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 i
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
>To: Francisco Corella
>Cc: Nat Sakimura ; matake nov ; Yuchen
>Zhou ; oauth ; Shu
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
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-behav
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
phil.h...@oracle.com
On 2012-06-15, at 3:06 PM, rui wang wrote:
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 clie
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 misunderstand
On 06/15/2012 07:54 PM, Mike Jones wrote:
> Bearer acknowledges Bill de hÓra. Core acknowledges Bill de hOra. Which is
> correct?
Bill may correct me but I believe the former is correct but
can't be represented in ASCII so the latter is what you ought
use.
S
There are cases where the OAuth specs specifically *prohibit* returning an
error code or other error information, for security reasons. For instance,
http://tools.ietf.org/html/draft-ietf-oauth-v2-bearer-20#section-3.1 contains
the language:
If the request lacks any authentication informati
Just to clarify, I was actually referring to the self-issued OpenID
Connect clients that Nat and others have been working on that sparked
this discussion of the utility of colon, not ones that we have here
locally in our implementations.
-- Justin
On 06/15/2012 02:58 PM, Mike Jones wrote:
Justin, it's a useful data point that you already have clients with colon (":")
in client_id values (that work because you aren't using HTTP Basic). Thanks
for letting us know that.
For the record, I'd be fine if the working group decided that %-encoding of
client_id values when used with HTTP
Bearer acknowledges Bill de hÓra. Core acknowledges Bill de hOra. Which is
correct?
-- Mike
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
So it's been pointed out to me that percent encoding like this would
break any clients that already have % in their client_id who are using
the Basic auth. My question to the group is: how many of these are out
there, really? Do we really have to worry about them? Right now, those
are just hypt
Thanks, Hannes. I believe that leaves the particulars of the ABNF and possible
encoding of client_id values containing colon for use with HTTP Basic as the
only open issues for Core.
-- Mike
-Original Message-
From: Hannes Tschofenig [mailto:hannes.tscho
Hi Mike,
I personally would find it better to have fewer SHOULDs. Most of them have been
there for a long time and so it is a bit late to complain but the challenge for
protocol architectures is to figure out under what conditions they should do
certain things.
Additionally, I don't buy the
Hi Mike,
thanks for raising this issue.
I am fine with the currently proposed approach. I just had a personal
preference for separate tables for readability purposes -- not a big issue.
Ciao
Hannes
On Jun 15, 2012, at 12:40 AM, Mike Jones wrote:
> Hi Hannes,
>
> You stated a preference fo
Why not percent encoding for just colon and percent?
-- Justin
On 06/15/2012 01:30 PM, Mike Jones wrote:
I was asked a question off-list, which I think is worth answering
on-line. The question was: Why the Tab character, rather than
%-encoding?
Introducing % encoding would break all exi
Aesthetically this makes my tummy hurt...
That said, I think it will work, and I'm willing to go with it.
>
> From: Mike Jones
>To: George Fletcher
>Cc: "oauth@ietf.org"
>Sent: Friday, June 15, 2012 10:30 AM
>Subject: Re: [OAUTH-WG] Dynamic clients, URI, an
+1
>
> From: Eran Hammer
>To: Mike Jones ; "oauth@ietf.org WG
>(oauth@ietf.org)"
>Sent: Thursday, June 14, 2012 11:32 PM
>Subject: Re: [OAUTH-WG] Section 7.2
>
>
>
>WFM.
>
>This will be the new text for 7.2 unless someone has any additional feedback
>or c
I was asked a question off-list, which I think is worth answering on-line. The
question was: Why the Tab character, rather than %-encoding?
Introducing % encoding would break all existing OAuth 2.0 deployments using
HTTP Basic. A non-starter...
Tab is legal in HTTP Basic but not in URLs or p
I agree with Eran that I prefer that this not be underspecified and that an
encoding for just colon for just Basic will suffice.
I'd suggested the encoding s/://g as a strawman. Are there any other
encoding proposals?
-- Mike
From: E
We should not leave this under specified. Picking an encoding for just Basic
and just colon is simple enough.
EH
On Jun 15, 2012, at 19:17, "Mike Jones"
mailto:michael.jo...@microsoft.com>> wrote:
Based on use cases I’m seeing, believe it’s important to allow the use of URIs
as client_id valu
+1
On Fri, Jun 15, 2012 at 10:17 AM, Mike Jones
wrote:
> Based on use cases I’m seeing, believe it’s important to allow the use of
> URIs as client_id values (which means allowing “:” in the client_id
> string). I’m OK with us either specifying a specific encoding when using
> them in Basic or s
Based on use cases I'm seeing, believe it's important to allow the use of URIs
as client_id values (which means allowing ":" in the client_id string). I'm OK
with us either specifying a specific encoding when using them in Basic or
simply saying that "When client_ids are used with HTTP Basic th
+1 for a simple encoding and allowing ':' in the client_id
On 6/13/12 6:53 PM, Amos Jeffries wrote:
On 14.06.2012 06:40, John Bradley wrote:
That would probably work as well. That is why I am not particularly
concerned about excluding the :
We originally used the URI itself, mostly for conve
28 matches
Mail list logo
