a simple workaround for lack of OAuth

17 views
Skip to first unread message

Amir Michail

unread,
Nov 22, 2008, 12:22:24 PM11/22/08
to Twitter Development Talk
Hi,

One could just have the user enter an assigned code into the bio/url
or even in a post (which would also help promote your service). Doing
so would allow the user to "claim" the twitter account and associate
it with his/her account in your service.

Unlike OAuth, this would even make future logins simpler.

Is this a reasonable way to go?

Amir

Chad Etzel

unread,
Nov 22, 2008, 12:26:43 PM11/22/08
to twitter-deve...@googlegroups.com
This is a good method to verify (claim) an account, yes... but if you wanted them to be able to do any sort of authenticated request (like tweeting or sending a direct message), you'd still need their password.  That is, unless you are asking twitter to change the way their API works.

By "future logins", do you mean to twitter? or to your service?

-Chad

Amir Michail

unread,
Nov 22, 2008, 12:30:11 PM11/22/08
to Twitter Development Talk
On Nov 22, 12:26 pm, "Chad Etzel" <jazzyc...@gmail.com> wrote:
> This is a good method to verify (claim) an account, yes... but if you wanted
> them to be able to do any sort of authenticated request (like tweeting or
> sending a direct message), you'd still need their password.  That is, unless
> you are asking twitter to change the way their API works.
>
> By "future logins", do you mean to twitter? or to your service?
>
> -Chad

It would simplify future logins to my service over even OAuth.

The problem for me though is that without user-specific authentication
(i.e., I use authentication under my account always), IP-based rate
limiting is a severe problem making this at best a temporary solution.

Amir

TCI

unread,
Nov 23, 2008, 2:33:00 PM11/23/08
to Twitter Development Talk
I find it better to get users to follow your account and then send
them a DM with a URL. Builds followers and eliminates errors from user
side.
R

Amir Michail

unread,
Nov 23, 2008, 8:19:35 PM11/23/08
to Twitter Development Talk
On Nov 23, 2:33 pm, TCI <ticoconid...@gmail.com> wrote:
> I find it better to get users to follow your account and then send
> them a DM with a URL. Builds followers and eliminates errors from user
> side.
> R

Are we allowed to have multiple accounts on twitter? If so, how many?

Amir

fastest963

unread,
Nov 24, 2008, 10:13:28 AM11/24/08
to Twitter Development Talk
@Amir That is not a very relevant question. Why do you want to make
multiple accounts?

@al3x A better alternative would be to just create an API key for
every user. Instead of entering username/password, they would enter
their secret API key?

Amir Michail

unread,
Nov 24, 2008, 12:30:36 PM11/24/08
to Twitter Development Talk
On Nov 24, 10:13 am, fastest963 <fastest...@gmail.com> wrote:
> @Amir That is not a very relevant question. Why do you want to make
> multiple accounts?

So users would follow an account with the same name as the service?

Anyway, I found out that creating multiple accounts is fine.

Amir

Stut

unread,
Nov 24, 2008, 12:53:37 PM11/24/08
to twitter-deve...@googlegroups.com
On 24 Nov 2008, at 15:13, fastest963 wrote:
> A better alternative would be to just create an API key for
> every user. Instead of entering username/password, they would enter
> their secret API key?

This is far less secure than OAuth and is actually not much better
than requiring a username and password.

One of the core benefits of OAuth is the ability to be very specific
regarding what each authorised application is allowed to do, on a per
application basis. It also allows you to selectively revoke the
permissions of any specific application without needing to ask or even
tell the application about it. To do this with the API key system you
effectively need to re-authorise every app you use when you want to
block just one of them. No real difference between this and having to
change your password.

I would much prefer that the guys (and gals) at Twitter concentrate on
getting OAuth properly implemented (which is harder than it sounds)
than their attention gets diverted by developers too impatient to wait
for the right solution to the problem.

-Stut

--
http://stut.net/

Alex Payne

unread,
Nov 24, 2008, 5:05:19 PM11/24/08
to twitter-deve...@googlegroups.com
We're currently waiting on our User Experience team to put the final
touches on a BETA release of our OAuth support. It's going to have
bugs, to be sure, but we should have it out there soon.

--
Alex Payne - API Lead, Twitter, Inc.
http://twitter.com/al3x

Amir Michail

unread,
Nov 26, 2008, 3:41:26 PM11/26/08
to Twitter Development Talk
On Nov 24, 5:05 pm, "Alex Payne" <a...@twitter.com> wrote:
> We're currently waiting on our User Experience team to put the final
> touches on a BETA release of ourOAuthsupport.  It's going to have
> bugs, to be sure, but we should have it out there soon.
>

Could you give us a time estimate? In a week? A month?

Amir

>
>
> On Mon, Nov 24, 2008 at 12:53, Stut <stut...@gmail.com> wrote:
>
> > On 24 Nov 2008, at 15:13, fastest963 wrote:
>
> >> A better alternative would be to just create an API key for
> >> every user. Instead of entering username/password, they would enter
> >> their secret API key?
>
> > This is far less secure thanOAuthand is actually not much better than
> > requiring a username and password.
>
> > One of the core benefits ofOAuthis the ability to be very specific
> > regarding what each authorised application is allowed to do, on a per
> > application basis. It also allows you to selectively revoke the permissions
> > of any specific application without needing to ask or even tell the
> > application about it. To do this with the API key system you effectively
> > need to re-authorise every app you use when you want to block just one of
> > them. No real difference between this and having to change your password.
>
> > I would much prefer that the guys (and gals) at Twitter concentrate on
> > gettingOAuthproperly implemented (which is harder than it sounds) than

Alex Payne

unread,
Nov 26, 2008, 6:38:12 PM11/26/08
to twitter-deve...@googlegroups.com
As I don't know the entire schedule of our UX team, I can't. I would
say less than a month and closer to a week by far, but please don't
hold me to that.

Richie

unread,
Dec 8, 2008, 11:16:22 AM12/8/08
to Twitter Development Talk
Hi Alex,

do you have any updates on when OAuth is available?

Currently I'm doing the finishing touches on a new service and would
love to let the users choose OAuth for authentication instead of
requiere them to give me their secret pw. I'm experienced in using
OAuth so I expect to get it working in a couple of hours.

Do you think Twitter will enable OAuth this week or should I start my
service with user/pw-authentication first?


Richard

Alex Payne

unread,
Dec 8, 2008, 12:09:54 PM12/8/08
to twitter-deve...@googlegroups.com
It won't be available for testing this week, but should be available
before the end of the month. I'd definitely encourage you not to
launch on it, though, as it will be a beta.

Richie

unread,
Jan 2, 2009, 12:44:48 AM1/2/09
to Twitter Development Talk
I think it's getting more urgent day by day:

http://scobleizer.com/2009/01/01/twitter-warning-your-data-is-being-sold/

Richie
http://twitter.com/RMetzler


On 8 Dez. 2008, 18:09, "Alex Payne" <a...@twitter.com> wrote:
> It won't be available for testing this week, but should be available
> before the end of the month.  I'd definitely encourage you not to
> launch on it, though, as it will be a beta.
>
>
>
> On Mon, Dec 8, 2008 at 08:16,Richie<rocketeer.so...@gmail.com> wrote:
>
> > Hi Alex,
>
> > do you have any updates on whenOAuthis available?
>
> > Currently I'm doing the finishing touches on a new service and would
> > love to let the users chooseOAuthfor authentication instead of
> > requiere them to give me their secret pw. I'm experienced in using
> >OAuthso I expect to get it working in a couple of hours.
>
> > Do you think Twitter will enableOAuththis week or should I start my

Cameron Kaiser

unread,
Jan 2, 2009, 12:53:15 AM1/2/09
to twitter-deve...@googlegroups.com
> I think it's getting more urgent day by day:
>
> http://scobleizer.com/2009/01/01/twitter-warning-your-data-is-being-sold/

Truly OAuth is needed, and is a priority to the Twitter team (they've said
so). However, there is nothing in the link that Scoble has up saying directly
that the buyer is planning to use the information Twply has harvested (namely
usernames and passwords) for nefarious purposes other than to continue
running the site. They certainly could, but Scoble needs to chill out a
little.

More to the point, there is nothing about OAuth that prevents a similar
bad actor from behaving badly. This older post puts it in perspective very
succinctly:

http://groups.google.com/group/twitter-development-talk/msg/16bf699d39c7f804

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- 10% of computer users [use] Mac ... the top 10 percent. -- Douglas Adams ---

Stuart

unread,
Jan 2, 2009, 1:09:32 AM1/2/09
to twitter-deve...@googlegroups.com
2009/1/2 Richie <rockete...@gmail.com>:

>
> I think it's getting more urgent day by day:
>
> http://scobleizer.com/2009/01/01/twitter-warning-your-data-is-being-sold/

I agree that OAuth can't arrive too soon, but this episode sucks
mainly because there is no need for something like twply to need your
password. This annoyed me so much that I spent this afternoon coding
up a site to prove that point.

Feedback greatly appreciated: http://replies.twitapps.com/

-Stuart

--
http://stut.net/

Cameron Kaiser

unread,
Jan 2, 2009, 1:11:25 AM1/2/09
to twitter-deve...@googlegroups.com
> I agree that OAuth can't arrive too soon, but this episode sucks
> mainly because there is no need for something like twply to need your
> password. This annoyed me so much that I spent this afternoon coding
> up a site to prove that point.
>
> Feedback greatly appreciated: http://replies.twitapps.com/

That's pretty clever. Nice work.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- Shady business do not make for sunny life. -- Charlie Chan -----------------

Dharmesh

unread,
Jan 2, 2009, 11:54:52 AM1/2/09
to Twitter Development Talk
Nicely done.

Quick question: How are you ensuring that you see *all* posts in the
public timeline? I didn't think that was quite possible yet with the
Twitter API.

On Jan 2, 1:11 am, Cameron Kaiser <spec...@floodgap.com> wrote:
> > I agree that OAuth can't arrive too soon, but this episode sucks
> > mainly because there is no need for something like twply to need your
> > password. This annoyed me so much that I spent this afternoon coding
> > up a site to prove that point.
>
> > Feedback greatly appreciated:http://replies.twitapps.com/
>
> That's pretty clever. Nice work.
>
> --
> ------------------------------------ personal:http://www.cameronkaiser.com/--
>   Cameron Kaiser * Floodgap Systems *www.floodgap.com* ckai...@floodgap.com

Stuart

unread,
Jan 2, 2009, 12:18:33 PM1/2/09
to twitter-deve...@googlegroups.com
2009/1/2 Dharmesh <dhar...@gmail.com>:
> Nicely done.

Thanks.

> Quick question: How are you ensuring that you see *all* posts in the
> public timeline? I didn't think that was quite possible yet with the
> Twitter API.

It's actually using the search API not the public timeline.

-Stuart

--
http://stut.net/

Ed Finkler

unread,
Jan 2, 2009, 1:22:32 PM1/2/09
to twitter-deve...@googlegroups.com
I think Scoble likes to hear himself talk, and loves to stir up drama.
It's how he keeps people paying attention to him.

I'd find more reputable sources for that argument.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron

Mark Ng

unread,
Jan 2, 2009, 1:36:09 PM1/2/09
to twitter-deve...@googlegroups.com
2009/1/2 Ed Finkler <funk...@gmail.com>:

>
> I think Scoble likes to hear himself talk, and loves to stir up drama.
> It's how he keeps people paying attention to him.
>
> I'd find more reputable sources for that argument.

Whilst there's an element of truth in your statement (just about all
of the prominent tech bloggers remain prominent by stirring up drama),
lots of people have been saying similar things for a long time. Ad
hominem attacks don't change the fact that the message is right. You
could start here : http://adactio.com/journal/1357 .

I think we all understand, however, that the twitter engineering team
first needed to make twitter stable before they could add features
like this one. Now that they've largely done that, it appears they're
responding to demand for features like this one, which is great news.

Mark

Cameron Kaiser

unread,
Jan 2, 2009, 1:41:25 PM1/2/09
to twitter-deve...@googlegroups.com
> > I think Scoble likes to hear himself talk, and loves to stir up drama.
> > It's how he keeps people paying attention to him.
> >
> > I'd find more reputable sources for that argument.
>
> Whilst there's an element of truth in your statement (just about all
> of the prominent tech bloggers remain prominent by stirring up drama),
> lots of people have been saying similar things for a long time. Ad
> hominem attacks don't change the fact that the message is right. You
> could start here : http://adactio.com/journal/1357 .

So let's say Scoble is right. How, in fact, does OAuth prevent a bad
actor from using credentials to act badly?

OAuth solves many problems; it doesn't solve this one.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- BOND THEME NOW PLAYING: "The Man With the Golden Gun" ----------------------

Ed Finkler

unread,
Jan 2, 2009, 1:41:49 PM1/2/09
to twitter-deve...@googlegroups.com
On Fri, Jan 2, 2009 at 1:36 PM, Mark Ng <ng.m...@gmail.com> wrote:

> Whilst there's an element of truth in your statement (just about all
> of the prominent tech bloggers remain prominent by stirring up drama),
> lots of people have been saying similar things for a long time. Ad
> hominem attacks don't change the fact that the message is right. You
> could start here : http://adactio.com/journal/1357 .

Agreed, and that's a much better source.

>
> I think we all understand, however, that the twitter engineering team
> first needed to make twitter stable before they could add features
> like this one. Now that they've largely done that, it appears they're
> responding to demand for features like this one, which is great news.

Yep. So not really a lot of point in continuing the "oh boy, this is a
big problem! thing, I think, when they're on it and have given many
updates here recently." That's not a criticism of you in particular,
but of folks who apparently don't search the archives before posting
something along the lines of "Scoble said this is a big deal, so you'd
better do it!" It doesn't help in any way.

Ed Finkler

unread,
Jan 2, 2009, 1:43:02 PM1/2/09
to twitter-deve...@googlegroups.com
On Fri, Jan 2, 2009 at 1:41 PM, Cameron Kaiser <spe...@floodgap.com> wrote:
> So let's say Scoble is right. How, in fact, does OAuth prevent a bad
> actor from using credentials to act badly?
>
> OAuth solves many problems; it doesn't solve this one.

And this.

Jesse Stay

unread,
Jan 2, 2009, 4:06:04 PM1/2/09
to twitter-deve...@googlegroups.com
On Thu, Jan 1, 2009 at 10:44 PM, Richie <rockete...@gmail.com> wrote:

It's true, OAuth doesn't really solve this problem, but the general public thinks it does.  Having some solution is better than none, and sometimes the feeling of security is better for marketing apps than no security at all.  I'd say the attention it's getting, and an entire app with open-text passwords being sold to a third party (which, who knows - maybe next time it's a spammer???) for a small price makes this pretty dang urgent.

Jesse

Cameron Kaiser

unread,
Jan 2, 2009, 4:10:44 PM1/2/09
to twitter-deve...@googlegroups.com
> > http://scobleizer.com/2009/01/01/twitter-warning-your-data-is-being-sold/

>
> It's true, OAuth doesn't really solve this problem, but the general public
> thinks it does. Having some solution is better than none, and sometimes the
> feeling of security is better for marketing apps than no security at all.

Maybe for apps, but not for users. A user that thinks he's secure and is
not is far worse off than a user who's insecure and knows he isn't. If this
makes people think about who they give credentials to -- OAuth or no -- then
the experience will be a painful but useful lesson.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- BOND THEME NOW PLAYING: "The World is Not Enough" --------------------------

Mark Ng

unread,
Jan 2, 2009, 4:27:47 PM1/2/09
to twitter-deve...@googlegroups.com
2009/1/2 Cameron Kaiser <spe...@floodgap.com>:

> So let's say Scoble is right. How, in fact, does OAuth prevent a bad
> actor from using credentials to act badly?
>
> OAuth solves many problems; it doesn't solve this one.

There are several problems to be solved, though.

The first is a malicious actor with access to a single system (in this
case, twitter) spamming. OAuth doesn't solve the problem of someone
using an account to spam using messages from that user (unless that
app doesn't need to message, and twitters OAuth implementation has
granular permissions).

The second is a malicious actor with access to a single system gaining
control of other systems that user has access to because they've used
the same username and/or password. Whilst this is bad practice on the
part of the user, we'd be silly to pretend that this isn't a large
problem. OAuth *does* solve that problem, which is one of the
problems in this scenario.

The third is a malicious actor with access to a single system locking
the user out of their own account (by changing their password) and
claiming the account for themselves (which has been known to happen
with gmail accounts, for example). Twitter, so far as I'm aware,
doesn't allow changes of passwords via the API, and I would assume
that an OAuth implementation would only allow access to the API, and
not the web interface. Even were these things not the case, it
wouldn't make sense to allow an OAuth client to change the user
password. So OAuth does solve this problem, also.

Mark

Cameron Kaiser

unread,
Jan 2, 2009, 4:41:48 PM1/2/09
to twitter-deve...@googlegroups.com
> > So let's say Scoble is right. How, in fact, does OAuth prevent a bad
> > actor from using credentials to act badly?
> >
> > OAuth solves many problems; it doesn't solve this one.
>
> There are several problems to be solved, though.

Clearly. But the point I'm making is that *this* particular situation isn't
solved by OAuth. You're absolutely right about the rest of the similar
issues it *does* improve -- no one is contesting OAuth's utility -- but it
wouldn't help this particular hypothetical situation.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com

-- Friends don't let friends use Windows. -------------------------------------

Chris Messina

unread,
Jan 2, 2009, 6:11:09 PM1/2/09
to Twitter Development Talk
On Jan 2, 11:06 am, "Jesse Stay" <jesses...@gmail.com> wrote:
>
> It's true, OAuth doesn't really solve this problem, but the general public
> thinks it does.  

Actually, it does.

With OAuth you can turn off a particular token, blocking a *specific*
application (i.e. Twply).

It doesn't prevent bad actors from behaving badly, but it does given
provide a pathway to give users more control over third-party access
to their account.

I'm not really sure why Twply needed a user's Twitter credentials in
the first place (but boy, they sure are easy to ask for!), but I
imagine it helps with getting private @replies (which search alone
won't give you).

In that case, Twitter could make it possible, like Flickr does, to
enable a third-party app to request certain permissions -- in this
case, a user's reply stream -- and nothing more.

So I disagree that OAuth doesn't solve this problem. At the bare
minimum it minimizes the scope of the inconvenience of needing to
change your Twitter password (and then changing it in all the other
Twitter apps that you use).

Chris

Jesse Stay

unread,
Jan 3, 2009, 4:31:59 AM1/3/09
to twitter-deve...@googlegroups.com
On Fri, Jan 2, 2009 at 4:11 PM, Chris Messina <chris....@gmail.com> wrote:

On Jan 2, 11:06 am, "Jesse Stay" <jesses...@gmail.com> wrote:
>
> It's true, OAuth doesn't really solve this problem, but the general public
> thinks it does.  

Actually, it does.

With OAuth you can turn off a particular token, blocking a *specific*
application (i.e. Twply).

It doesn't prevent bad actors from behaving badly, but it does given
provide a pathway to give users more control over third-party access
to their account.

Well put Chris - I had forgotten about that.  I just want something - I don't care what, but I need it soon, as it's starting to make it really difficult to market my App and keep users feeling secure.  I *hate* knowing my users Twitter passwords (I have over 5,000 of them - it's really scary that I do).  I sincerely hope this is top priority for Twitter right now - it should have been implemented last year so long as they have an API in place.  On my App, it took about 2 hours max to write, test, and implement a very simple API key system like this for the API I'm providing. I don't get why it's taking Twitter so long.

Jesse

Ed Finkler

unread,
Jan 3, 2009, 2:13:38 PM1/3/09
to twitter-deve...@googlegroups.com
Whether its writing books or developing applications, it's typically
bad form to assume your own experience mirrors others' experience when
doing a similar type of activity. Generally leads to incorrect
assumptions.

If you don't like what your application does, or find it hard to do
what you want, I might also suggest that you developed your
application at the wrong time. Making financial commitments that rely
on a service which you have no agreement to level or service seems
like a bad idea.

--
Ed Finkler
http://funkatron.com
AIM: funka7ron
ICQ: 3922133
Skype: funka7ron

Ed Finkler

unread,
Jan 3, 2009, 2:14:11 PM1/3/09
to twitter-deve...@googlegroups.com
That should be "level of service."

Jesse Stay

unread,
Jan 3, 2009, 11:06:28 PM1/3/09
to twitter-deve...@googlegroups.com
On Sat, Jan 3, 2009 at 12:13 PM, Ed Finkler <funk...@gmail.com> wrote:

Whether its writing books or developing applications, it's typically
bad form to assume your own experience mirrors others' experience when
doing a similar type of activity. Generally leads to incorrect
assumptions.

If you don't like what your application does, or find it hard to do
what you want, I might also suggest that you developed your
application at the wrong time. Making financial commitments that rely
on a service which you have no agreement to level or service seems
like a bad idea.

So I guess all us developers just give up? The fact is plain text passwords are part of the API, and the only way to write apps. Twitter hasn't removed that from the API, so it's the only way to write apps right now. People aren't going to stop doing that, and that's a huge issue.

It's very easy to do what I want to do. I like what my application does. I don't like how Twitter is making me do it though. I'm up for a boycott if you can convince my competitors to do so as well - good luck with that.

Jesse

Ed Finkler

unread,
Jan 4, 2009, 12:17:03 PM1/4/09
to twitter-deve...@googlegroups.com
I wouldn't have chosen to create an application like yours under the current environment. It seems unwise to do so to me. YMMV. 

Sent from my drmPhone

Chris Messina

unread,
Jan 4, 2009, 2:23:45 PM1/4/09
to Twitter Development Talk
On Jan 2, 11:31 pm, "Jesse Stay" <jesses...@gmail.com> wrote:

> Well put Chris - I had forgotten about that.  I just want something - I
> don't care what, but I need it soon, as it's starting to make it really
> difficult to market my App and keep users feeling secure.  I *hate* knowing
> my users Twitter passwords (I have over 5,000 of them - it's really scary
> that I do).  I sincerely hope this is top priority for Twitter right now -
> it should have been implemented last year so long as they have an API in
> place.  On my App, it took about 2 hours max to write, test, and implement a
> very simple API key system like this for the API I'm providing. I don't get
> why it's taking Twitter so long.

John Adams from Twitter's operations team replied to my post on this
subject:

"The plan is to support Basic Auth and OAuth concurrently, for at
least 6 months, if not more.

"We can’t completely turn off the Basic Auth API without having a
large impact to many APIs and clients."

http://factoryjoe.com/blog/2009/01/02/twitter-and-the-password-anti-pattern/comment-page-1/#comment-103431

So, you will be given an option (no telling when) to use OAuth instead
of the plaintext username/password combo.

Of course it means many folks will still use the lowest common
denominator (and the most insecure method available) for some time,
but at least there will be a good transitional time period where
developers who want to use OAuth can do so, paving a path for those
who will need to migrate later.

Heck if Flickr could get its user base to move over to Yahoo accounts,
I imagine Twitter will be able to get app developers and users to move
over to OAuth in six months.

Chris

Alex Payne

unread,
Jan 4, 2009, 4:39:12 PM1/4/09
to twitter-deve...@googlegroups.com
We'll certainly be doing our utmost to incentivize developers to move
to OAuth. The next major version of the API will be OAuth-only, for
example.

Of course, once we offer OAuth, it would be nice to see the same
community pressure that's been applied to us put towards companies
like Amazon. The Amazon.com iPhone app collects my username and
password, and that account is actually tied to my credit card
information. Where are the blog posts about their anti-patterns?