On 4/17/09 7:00 PM, John Kristian wrote:
> OAuth concentrates on securing communication between the consumer and
> service provider. The callback is just a timing signal, telling the
> consumer it can continue its interaction with the service provider.
> Nothing sensitive is transmitted via the c
OAuth concentrates on securing communication between the consumer and
service provider. The callback is just a timing signal, telling the
consumer it can continue its interaction with the service provider.
Nothing sensitive is transmitted via the callback.
In other words, attempting to transmit
On 4/17/09 4:20 PM, Dirk Balfanz wrote:
> Why? OAuth doesn't need it. It's not an authentication protocol.
That's such a sad oversight of the initial OAuth specification. I hope
we can fix this in future versions of the spec.
> Once you start going down this route, you'll realize that you also
Dossy Shiobara wrote:
> On Apr 17, 10:32 am, Breno wrote:
>
>> Sorry, Eran, but it is not an authentication protocol. An
>> authentication protocol must be signed by the authenticator, not by
>> the authentication requester.
>>
>
> OMG YES!
>
> Can OAuth 1.1 _please_ fix this and make sign
On Fri, Apr 17, 2009 at 12:27 PM, Dossy Shiobara wrote:
>
> On Apr 17, 10:32 am, Breno wrote:
>> Sorry, Eran, but it is not an authentication protocol. An
>> authentication protocol must be signed by the authenticator, not by
>> the authentication requester.
>
> OMG YES!
>
> Can OAuth 1.1 _pleas
OpenID already has a standardized way to get the user's profile data
(name, avatar image, email address) via SREG/AX without having to write
any vendor-specific code. There's no equivalent to do this in OAuth,
although PoCo will eventually take care of this, once discovery is
implemented.
I al
On Apr 17, 10:32 am, Breno wrote:
> Sorry, Eran, but it is not an authentication protocol. An
> authentication protocol must be signed by the authenticator, not by
> the authentication requester.
OMG YES!
Can OAuth 1.1 _please_ fix this and make signing of the callback URL
by the OAuth producer
Some recent posts reminded me that an OAuth consumer should carefully
maintain a session with the user, to prevent an attacker from
impersonating the user. You don't want the consumer to treat an
attacker's browser as though it belongs to the user who authorized
access. There are techniques for
'Sign in with Twitter' might be useful.
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/73524da521d3081c?hl=en
http://groups.google.com/group/oauth/browse_thread/thread/583720b6cc447e7b?hl=en
--~--~-~--~~~---~--~~
You received this mess
Right, OAuth is an authorization system. I wonder if we should change
the marketing literature to say as much. Maybe it would just baffle
people ...
The folks at Twitter are having difficulty applying OAuth to
authentication.
http://groups.google.com/group/twitter-development-talk/browse_thread
Please note: I am not claiming that OAuth is insecure in any way. It
is a secure protocol for the purposes of data access authorization,
for which it was designed. I am just expressing serious doubts that it
can be re-targeted for another purpose: authentication.
It is very rarely the case that a
Example attack:
Example.com accepts authentication from Example-Provider.com
User A wants to login as any other user at Example.com to steal the
data that those users have saved at Example.com.
User A goes to Example.com and clicks on 'sign in using
example-provider.com'; He receives a well-for
And how is it any different from an OpenID request without association? The RP
has to go over to the IDP and ask it if the signed request is valid (as opposed
to if the token/secret pair is valid and authorized).
EHL
> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@goo
How does this distinction make this solution any less secure? What exploits are
possible here and not, say, using OpenID or HTTP Basic Auth?
EHL
> -Original Message-
> From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
> Of Breno
> Sent: Friday, April 17, 2009 7:33 A
Sorry, Eran, but it is not an authentication protocol. An
authentication protocol must be signed by the authenticator, not by
the authentication requester.
On Fri, Apr 17, 2009 at 12:26 AM, Eran Hammer-Lahav wrote:
> Of course it is an authentication protocol. You make authenticated API
> requ
Of course it is an authentication protocol. You make authenticated API
requests. It is also a delegation protocol in the way usernames and passwords
are exchanged for tokens.
The only thing it doesn't have that OpenID has is discovery, but since it is a
single vendor solution, it doesn't need a
16 matches
Mail list logo
