Sign in with Twitter

[John Kristian]

Re: http://apiwiki.twitter.com/Sign%20in%20with%20Twitter

Would it be practical to change oauth/authenticate, so it's less
challenging to a user who isn't logged in and hasn't authorized the
application? In this case, I'd prefer that the user see a single page
like oauth/authorize, which enables the user to login and give
permission in one step.

Currently, oauth/authenticate shows two pages in this case: one to
enter credentials and a second to allow access. If it were one page,
fewer users would abandon the effort. It would also be less
mystifying: a user who's focused on the application won't see the
first page and wonder, "Why must I log in to Twitter? I want to use
<application>, not the Twitter website."

[Coderanger]

I would agree, this area needs some TLC as my post suggested:
http://groups.google.com/group/twitter-development-talk/browse_thread/thread/0f57965561504a1c?hl=en

[Duane Roelands]

If your users don't understand why they're seeing the Twitter login
screen, then your application needs to do a better job of explaining
it.

[Jesse Stay]

On Wed, Aug 5, 2009 at 7:32 AM, Duane Roelands <duane.r...@gmail.com> wrote:

If your users don't understand why they're seeing the Twitter login
screen, then your application needs to do a better job of explaining
it.

Duane I don't think this has anything to do with that. Having worked on e-commerce sites for major e-commerce companies, it has been proven that the more steps a user has to register, the more likely they are to abandon the process, and the more likely you are to lose a sale.  This is why Amazon patented the one-click sale. The fact is this (Twitter's auth) takes too many steps, and no amount of explaining ahead of time is going to change that.  The more you can keep the users on your own site and reduce the steps necessary to log in, the better.

Again, as I mentioned earlier - with Facebook this is one step: click a button, enter your credentials (if you haven't already), and you're done, and they never leave your site to do it.  I'd love to see the same for Twitter with unauthenticated users, especially removing the need for them to leave my site to make the authentication happen.

Jesse

[Dewald Pretorius]

Jesse,

Amen to that.

When one does customer support for long enough, you quickly realize
that:

a) People do not read instructions, and

b) Many people are not as computer literate as you'd wish them to be.

If you send people all over the place, many go, "WTF," and abandon the
process out of fear or ignorance.

With Basic Auth the process is very simple. Enter the username and
password on your site, and click the save button. It shouldn't be any
more involved or complicated with OAuth.

Dewald

On Aug 6, 2:22 am, Jesse Stay <jesses...@gmail.com> wrote:

[John Kristian]

It's a subtle distinction: users aim to use the application, not the
Twitter website. They expect Twitter to ask for their permission, but
they don't expect to start using the Twitter website. So they're a
little surprised when Twitter asks them to log in. The page doesn't
make it clear that they're moving toward the application; it looks
like they're moving toward Twitter's UI.

Of course the application can warn the user what's going to happen,
but I'd prefer to remove the cognitive dissonance.

[Chris Babcock]

On Thu, 6 Aug 2009 05:09:48 -0700 (PDT)
Dewald Pretorius <dpr...@gmail.com> wrote:

> Amen to that.
>
> When one does customer support for long enough, you quickly realize
> that:
>
> a) People do not read instructions, and
>
> b) Many people are not as computer literate as you'd wish them to be.
>
> If you send people all over the place, many go, "WTF," and abandon the
> process out of fear or ignorance.
>
> With Basic Auth the process is very simple. Enter the username and
> password on your site, and click the save button. It shouldn't be any
> more involved or complicated with OAuth.

The problem with Basic Auth is that it doesn't know the difference
between Authentication and Authorization. It's an oversimplification.
The only way to do something *for* someone is to *be* that someone as
far as the target system is concerned. A system that is as smart as it
needs to be is going to be a little more complicated and involved than
that.

You can still do a little animated "authorize this" screen just like
Facebook with OAuth. Just set up a gateway on your server and Ajax the
whole work flow through the gateway. There's no need to complicate the
UX. The complications can go in the back end so that you can get your
authenticalization in one click.

Chris Babcock

[John Kristian]

Some users aren't comfortable giving their Twitter password to another
website. For them, it's sort of a good thing to be sent to Twitter's
UI to authenticate; it builds confidence that their credentials won't
be abused. I'm looking for a sweet spot, where the user knows Twitter
is participating but is primarily thinking about using the
application.

[Dewald Pretorius]

Chris,

If I understand you correctly, you're saying one should login for the
user in the OAuth process? Wouldn't that involve scraping the Twitter
web interface? Or am I outside the ballpark with my understanding?

Dewald

>  signature.asc
> < 1KViewDownload

[Coderanger]

> Some users aren't comfortable giving their Twitter password to another
> website.  For them, it's sort of a good thing to be sent to Twitter's

I would hazard a guess that they really are the long tail. Only a
small percentage of people would care, most would not but they are
going to be penalized with a more complicated system ... seems a bit
backward to me.

One possibility is for your application (which is what I will do in
twitcher) to offer both methods. Then both sets of users are covered,
most people can get in quickly and easily by entering name and
password; but those that are more careful/concerened can go the more
complicated oauth route.

Problem is, twitter are going to shut off Basic Auth at some point
which is a big mistake IMHO, but hey ho.

[Chris Babcock]

On Thu, 6 Aug 2009 08:50:05 -0700 (PDT)
Dewald Pretorius <dpr...@gmail.com> wrote:

> If I understand you correctly, you're saying one should login for the
> user in the OAuth process? Wouldn't that involve scraping the Twitter
> web interface? Or am I outside the ballpark with my understanding?

I'm saying that, for those who are more worried about losing users with
an OAuth login than they are worried about losing them by asking for
their Twitter password, it is still possible and desirable to use OAuth.

There is a complexity cost, but you can pay it in the back end instead
of passing it on to the user interface. The benefits are that the
application isn't subject to the verify credentials DoS attack and the
app will already be using OAuth if/when basic is discontinued.

With OAuth, you authenticate the user, but you never use the verify
credentials service to do so. Even if you set up a gateway so that you
can use Ajax to log the user into Twitter and verify your own token, you
don't verify credentials so much as use them.

The API documentation is saying that the OAuth calls aren't rate
limited. They don't need to be for security, but they may need to be
limited by IP address for performance. The main point is that a user
outside of your service can't trip the limit in order to run a DoS
attack on your users.

Chris Babcock