Picture upload using OAuth

3 views
Skip to first unread message

Harshad

unread,
Jan 10, 2010, 7:03:07 AM1/10/10
to Dabr
Hi,

I have created an API for uploading images to twitter via OAuth here:
http://tdash.org/api.html

Is this something that will interest Dabr users/developers?
I would appreciate your comments.

Note that the API isn't live yet. I am just trying to get feedback
from developers.

cheers,
Harshad

David Carrington

unread,
Jan 10, 2010, 7:12:02 PM1/10/10
to da...@googlegroups.com
If you want the OAuth details of other apps, and it's users, then you
are breaching the trust of everyone involved. On the other hand, if
users signed into your site through Twitter's OAuth and you provided a
unique key/authentication yourself that could be stored on the client
then at least you don't have the option of sending spam on behalf of
someone else's app.

Either way, it's not a good idea with the way OAuth currently works.

Dave

Harshad RJ

unread,
Jan 10, 2010, 10:02:26 PM1/10/10
to da...@googlegroups.com
I agree with your points.

But IMO, the user's security is more important than the App's. Moreover, both the user and App can recreate invalidate their old keys (in the worst case).

With password based auth, the user loses all privacy, and there is no safety net. Even resetting the password may not be possible if the account is compromised, and even if the user manages to reset the password, all apps stop working.

So, the three choices that are currently available:
  • Wait for OAuth delegation to mature - The safest for everyone
  • Share OAuth keys - safe for the User but not for the App
  • Share Passwords - unsafe
Currently, app developers are using the third option. I am hoping that my proposal, while not the best option, is better than the third.

Harshad RJ

unread,
Jan 11, 2010, 10:01:09 AM1/11/10
to da...@googlegroups.com
On Mon, Jan 11, 2010 at 5:42 AM, David Carrington <david.ca...@gmail.com> wrote:
On the other hand, if
users signed into your site through Twitter's OAuth and you provided a
unique key/authentication yourself that could be stored on the client
then at least you don't have the option of sending spam on behalf of
someone else's app.

Oops! I hadn't understood this fully in the first parse. This is a good option from security point of view, but the problem is that the work-flow is too complicated for the end-user.

-- 
Harshad RJ
http://hrj.wikidot.com
Reply all
Reply to author
Forward
0 new messages