A New API For Browserless Apps?

[Duane Roelands]

If we're talking about replacing the "PIN Workflow", then this is a
good idea. If we're talking about completely different interfaces for
web and desktop apps, I can't see how that's an improvement.

Seeing as the Search API is still not in line with the rest of the
API, does this mean that we're going to have three disparate
incompatible interfaces to juggle?

How is that an improvement?

[Rich]

Also if you're going to make changes to oAuth and the way it works
currently... please bear in mind many of us already have production
apps using oAuth.

Maybe you could move the oAuth to versioning to allow us time to move
to newer methods as and when you release them?

[Raffi Krikorian]

we're not making any fundamental changes to oauth - your apps should
continue to work fine.

the changes that we are making involve implementing
http://tools.ietf.org/html/draft-dehora-farrell-oauth-accesstoken-creds-00#section-4.
this will allow applications to obtain oauth tokens for a user given
the user's username / password.

--
Raffi Krikorian
Twitter Platform Team
http://twitter.com/raffi

[srikanth reddy]

Does that mean the PIN work flow  will go away?. The given below approach may be fine with console based/browserless apps. But i would still prefer the the PIN based workflow for desktop apps (which can invoke browser for authentication) as users do not prefer sharing their passwords.

[Raffi Krikorian]

i do not believe we are deprecating the pin workflow, we are adding
another option.

> Does that mean the PIN work flow  will go away?. The given below approach
> may be fine with console based/browserless apps. But i would still prefer
> the the PIN based workflow for desktop apps (which can invoke browser for
> authentication) as users do not prefer sharing their passwords.
>

[John Meyer]

On 12/10/2009 6:22 AM, Raffi Krikorian wrote:
> we're not making any fundamental changes to oauth - your apps should
> continue to work fine.
>
> the changes that we are making involve implementing
> http://tools.ietf.org/html/draft-dehora-farrell-oauth-accesstoken-creds-00#section-4.
> this will allow applications to obtain oauth tokens for a user given
> the user's username / password.
>
>

okay, forgive me if I'm wrong, but wasn't the whole point of oAuth that
the application didn't need to know the username/password? That the
user would grant access to the application and then the application
would store that rather than the actual username/password. Or am I
missing the point of going to an oAuth system?

[ryan alford]

I was thinking the same.

[srikanth reddy]

Me too.
Don't know if there is any compelling reason on twitter to allow third party apps send username/password for oAuth. FriendFeed is also allowing this.

Now All those thirdparty apps who already store username/passwords (for Basic auth) and those who use other third party servies like twitpic will be happy about this as nothing changes from UX point of view. But is this oAuth?

[Michael Ekstrand]

John Meyer wrote:
> okay, forgive me if I'm wrong, but wasn't the whole point of oAuth
> that the application didn't need to know the username/password? That
> the user would grant access to the application and then the
> application would store that rather than the actual
> username/password. Or am I missing the point of going to an oAuth
> system?

Yes, that's the point of OAuth. However, the dynamics of a web-based
application vs. a desktop application complicate things. If the user is
trusting an application to run natively on their desktop, that
application already has access to their username and password (it can
read them from config files, do a keyboard grab when it spawns the
browser, go snooping around in Firefox's memory space, any number of
things). Thus, in the desktop application case, allowing the user to
input their username and password does not decrease security except
perhaps by not always enforcing "don't give away your password". The
web case is different - a web site doesn't have the user's credentials
unless they explicitly provide them.

I'm ignoring for the present sandboxed or sandboxable environments such
as Java and AIR. The runtime may prevent the local application from
having access to the username/password as used by other applications.

- Michael

--
mouse, n: A device for pointing at the xterm in which you want to type.
Confused by the strange files? I cryptographically sign my messages.
For more information see <http://www.elehack.net/resources/gpg>.

[srikanth reddy]

@ michael

" The web case is different - a web site doesn't have the user's credentials
unless they explicitly provide them."

With the new  oAuth implementation even web apps will be allowed to collect user's credentials. There is no way to enforce webapps to delegate authentication

[Raffi Krikorian]

precisely.

in a web scenario, developers are encourage to go through the web
workflow - this new workflow is for those environments where bringing
up a browser is impossible (embedded devices), cumbersome, or would
destroy the UX experience. i would love to see developers message to
their users that they are "secure" in that they are using OAuth, but i
realise that is a complicated thing to get across easily.

[Raffi Krikorian]

don't be evil. in a web scenario, send them to twitter.com for the
oauth workflow. in the case that you can't do that, do not store the
username and password - simply pass them through and store the tokens
instead.

[Cameron Kaiser]

> don't be evil. in a web scenario, send them to twitter.com for the
> oauth workflow. in the case that you can't do that, do not store the
> username and password - simply pass them through and store the tokens
> instead.

*And* reinforce to users that 3rd party web services should use OAuth, not
u/p, and encourage them to use services that use true OAuth so that users
agree that those web services offering it offer them value.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- This signature is free of dihydrogen monoxide! Ban it now! www.dhmo.org ----

[Isaiah]

This seems like a dramatic improvement to me.  When will Twitter start rolling out support for this, I'd like to be ready with something on github for this as soon as it lands.

Isaiah

YourHead Software

sup...@yourhead.com

http://www.yourhead.com

[Dewald Pretorius]

Raffi,

Can this method be used to migrate users from a Basic Auth app to an
OAuth app?

Wouldn't it be great and so much easier if I could migrate all my
users, for whom I already have the username and password, with this
method. I can do that in one afternoon.

Dewald

On Dec 10, 11:42 am, Raffi Krikorian <ra...@twitter.com> wrote:
> don't be evil.  in a web scenario, send them to twitter.com for the
> oauth workflow.  in the case that you can't do that, do not store the
> username and password - simply pass them through and store the tokens
> instead.
>
>
>
> > @ michael
> > " The web case is different - a web site doesn't have the user's credentials
> > unless they explicitly provide them."
> > With the new  oAuth implementation even web apps will be allowed to collect
> > user's credentials. There is no way to enforce webapps to delegate
> > authentication
>

> > On Thu, Dec 10, 2009 at 8:42 PM, Michael Ekstrand <mich...@elehack.net>

[Raffi Krikorian]

hi dewald.

that's one of the design goals, so yes :P

[Dewald Pretorius]

That is REALLY cool. It turns migrating thousands of users to OAuth
from being a huge and frustrating exercise into a leisurely stroll in
the park.

[Michael Steuer]

Raffi - can someone at Twitter PLEASE comment on the delegation question? If
your app uses the web oauth flow, as strongly recommended by Twitter and
reiterated in your statement below, how do you see consumption of 3rd party
APIs happening when you don't have the user's un/pw? I don't understand why
you're so unwilling to address that question?

[Raffi Krikorian]

we're not unwilling to answer the question.  it is something we're actively working on, and we're just not in a state to release anything yet.

[Michael Steuer]

Great to hear it’s on your radar and you’re actively working on it. Any chance you’ll involve the dev community prior to presenting the solution as a fait-accompli? And do you have an idea around timing for this solution?

On 12/10/09 9:55 AM, "Raffi Krikorian" <ra...@twitter.com> wrote:

we're not unwilling to answer the question.  it is something we're actively working on, and we're just not in a state to release anything yet.

On Thu, Dec 10, 2009 at 9:52 AM, Michael Steuer <mst...@gmail.com> wrote:

Raffi - can someone at Twitter PLEASE comment on the delegation question? If
your app uses the web oauth flow, as strongly recommended by Twitter and
reiterated in your statement below, how do you see consumption of 3rd party
APIs happening when you don't have the user's un/pw? I don't understand why
you're so unwilling to address that question?


On 12/10/09 7:42 AM, "Raffi Krikorian" <ra...@twitter.com> wrote:

> don't be evil.  in a web scenario, send them to twitter.com <http://twitter.com>  for the

[Raffi Krikorian]

Great to hear it’s on your radar and you’re actively working on it. Any chance you’ll involve the dev community prior to presenting the solution as a fait-accompli? And do you have an idea around timing for this solution?

yes, and no. :P 

[Duane Roelands]

Many of us in the developer community have been strongly pushing the
point of view that third-party apps should never be asking for user
credentials. We did so because we believed that Twitter was firmly
committed to the security of the ecosystem and protecting the accounts
of its users. It now appears that this belief was in error.

This decision is going to actively hurt developers who chose the
more secure implementation. Application A just lets me log in with my
Twitter credentials, but Application B wants me to go through this
harder process. Most users will choose option A, and the more-secure
application B loses users. this decision punishes developers who
chose the more secure model. It's disappointing, because a lot of
developers have worked very hard to bring OAuth implementations to the
community that were robust and secure and **didn't require a user to
hand over their Twitter credentials**.

There was a great opportunity here for Twitter to be a security leader
in the social network space by saying "We don't want our users giving
their Twitter credentials to anyone except Twitter". It's a shame
they didn't stick to their gun; the result is going to be a less-
secure ecosystem.

[Michael Steuer]

I agree with Duane... A lot of us have implemented oAuth on Twitter's strong
urging and continue to be "punished" for it by none other than Twitter... Of
course consumers will prefer clients with the easier log in flow, giving
unfair benefit to apps that just request the un/pw instead of redirecting to
Twitter (realize that though we all know that it's not advisable to give
your Twitter credentials to a third party site, however 90% of the consumers
out there wouldn't think twice about it and will make their choice based on
ease of use). And secondly, yes I am a broken record on this topic, the
inability to consume or provide 3rd party APIs from/to apps that rely on
oAuth, as delegation isn't supported (though Raffi confirmed this morning
that sometime between now and when hell freezes over, Twitter will provide a
solution to this).

If it's now Twitter's stance that it's okay to ask your users for their
Twitter un/pw, then let's all switch to that immediately... It'll allow me
to consumer and/offer 3rd party APIs, I can use basic auth for the next 6.5
months, and then switch to this proposed fake oauth in June by requesting
tokens using the user's username/password...

[Dewald Pretorius]

Apps that provide an API should implement their own API authentication
scheme.

In all honesty, I do not think it should be Twitter's problem.

An app can very easily provide the user with a unique API key, such as
the one used by bit.ly and FriendFeed (initially), that your user must
enter in your application for it to operate on the other app's API on
behalf of your user. That means your user must authorize the API app
to operate on her Twitter account, and depending on the nature of your
app, do the same for your app as well. That makes sense. Piggy-backing
your app off the authorization of another app does not makes sense.

As far as the concern that existing Basic Auth apps suddenly have a
strategic advantage over existing OAuth apps, the following:

a) If it is true that 90% of all users prefer the convenience of a
Basic Auth solution, then why are we forcing a more cumbersome
solution down their throats? There will always be some form of Basic
Auth in some of the apps. My app will always do its primary local site
authentication via username and password, because I am not going to
tie my user authentication to and depend on one external service.

b) The proposed method makes migration of existing users to OAuth very
easy because one can now simply run a one-time batch script to obtain
the tokens from Twitter and replace the Twitter username and password
with those tokens. For new users of your site, you can still follow
the standard OAuth pin workflow without asking for their Twitter
credentials, in order to obtain the tokens.

c) Will some apps decide to continue to ask for Twitter credentials
and obtain the tokens with this alternate method? Probably. But, the
support load created by users changing their Twitter credentials
without understanding the need to make the corresponding change in
your app, makes the normal OAuth worklflow a far better solution.

On Dec 10, 2:01 pm, Michael Steuer <mste...@gmail.com> wrote:
> Great to hear it¹s on your radar and you¹re actively working on it. Any
> chance you¹ll involve the dev community prior to presenting the solution as
> a fait-accompli? And do you have an idea around timing for this solution?
>
> On 12/10/09 9:55 AM, "Raffi Krikorian" <ra...@twitter.com> wrote:
>
>
>
> > we're not unwilling to answer the question.  it is something we're actively
> > working on, and we're just not in a state to release anything yet.
>

> > On Thu, Dec 10, 2009 at 9:52 AM, Michael Steuer <mste...@gmail.com> wrote:
> >> Raffi - can someone at Twitter PLEASE comment on the delegation question? If
> >> your app uses the web oauth flow, as strongly recommended by Twitter and
> >> reiterated in your statement below, how do you see consumption of 3rd party
> >> APIs happening when you don't have the user's un/pw? I don't understand why
> >> you're so unwilling to address that question?
>
> >> On 12/10/09 7:42 AM, "Raffi Krikorian" <ra...@twitter.com> wrote:
>
> >>> > don't be evil.  in a web scenario, send them to twitter.com
> >>> <http://twitter.com>  for the
> >>> > oauth workflow.  in the case that you can't do that, do not store the
> >>> > username and password - simply pass them through and store the tokens
> >>> > instead.
>
> >>>> >> @ michael
> >>>> >> " The web case is different - a web site doesn't have the user's
> >>>> credentials
> >>>> >> unless they explicitly provide them."
> >>>> >> With the new  oAuth implementation even web apps will be allowed to
> >>>> collect
> >>>> >> user's credentials. There is no way to enforce webapps to delegate
> >>>> >> authentication
>

> >>>> >> On Thu, Dec 10, 2009 at 8:42 PM, Michael Ekstrand <mich...@elehack.net>

[Michael Ekstrand]

Duane Roelands wrote:
> There was a great opportunity here for Twitter to be a security leader
> in the social network space by saying "We don't want our users giving
> their Twitter credentials to anyone except Twitter". It's a shame
> they didn't stick to their gun; the result is going to be a less-
> secure ecosystem.
>

One potential middle ground, that would require enforcement manpower but
potentially create a win-win scenario, is to say that web apps are not
allowed to use the u/pw OAuth flow except as a migration strategy, and
punish (by deactivation) apps that do not comply.

[Dave Sherohman]

On Thu, Dec 10, 2009 at 07:33:28AM -0700, John Meyer wrote:
> okay, forgive me if I'm wrong, but wasn't the whole point of oAuth that
> the application didn't need to know the username/password? That the
> user would grant access to the application and then the application
> would store that rather than the actual username/password. Or am I
> missing the point of going to an oAuth system?

That is *a* point of oauth, not *the* point.

It's probably the most obvious point from a naive end-user viewpoint,
but there are also other advantages to oauth, even when the keys are
obtained by entering your username/password. Just off the top of my
head:

- The app doesn't need to store your username/password in a retrievable
format, so an attacker who compromises the application's data store
will not gain access to them.

- Your username/password will not be transmitted across the internet or
wireless LAN connections on every request made, which greatly reduces
the window of vulnerability for an attacker to intercept them in
transit.

- You can change your Twitter username and/or password without then
having to immediately reauthorize the app by re-entering the new
username/password.

- Conversely, if you wish to revoke a specific app's access, you can do
so without affecting any other application. (Unless the app in
question has stored your username/password in a retrievable format, in
which case it could just get new oauth credentials, of course.)

- If oauth is the only allowed authentication method, a rogue app would
not be able to gain full access to your account. Perhaps most
importantly, it would not be capable of changing your password and
locking you out.

- On Twitter's side, I'm sure it will simplify things considerably for
all API methods to support only a single authentication method.

--
Dave Sherohman

[Dave Sherohman]

On Thu, Dec 10, 2009 at 10:40:20AM -0800, Duane Roelands wrote:
> Many of us in the developer community have been strongly pushing the
> point of view that third-party apps should never be asking for user
> credentials. We did so because we believed that Twitter was firmly
> committed to the security of the ecosystem and protecting the accounts
> of its users. It now appears that this belief was in error.

I see no evidence that Twitter is anti-security here.

> This decision is going to actively hurt developers who chose the
> more secure implementation. Application A just lets me log in with my
> Twitter credentials, but Application B wants me to go through this
> harder process. Most users will choose option A, and the more-secure
> application B loses users. this decision punishes developers who
> chose the more secure model. It's disappointing, because a lot of
> developers have worked very hard to bring OAuth implementations to the
> community that were robust and secure and **didn't require a user to
> hand over their Twitter credentials**.

1) Given that third-party apps are currently able to request username/
password and use them for Basic Auth, I do not see how apps being able
to request username/password and use them for oauth makes things any
worse. I can see an (IMO weak) argument that this may prevent things
from getting better, but it will not make them worse.

2) I seem to be the odd man out here, but I consider the current oauth
web application auth method (which I'm assuming is "the more-secure
application B") to be the easier method. Click-click-click, done. No
typing in my username or remembering my password required. Username/
password is definitely the more familiar method for most users, since
it's what they've been using all their (online) lives, but I reject your
assertion that it's easier to complete.

> There was a great opportunity here for Twitter to be a security leader
> in the social network space by saying "We don't want our users giving
> their Twitter credentials to anyone except Twitter". It's a shame
> they didn't stick to their gun; the result is going to be a less-
> secure ecosystem.

They still can stick to their guns and say "We don't want our users
giving their Twitter credentials to any *web site or desktop
application* except Twitter." It seems clear to me from Raffi's
comments on it that this third oauth flow is intended solely to enable
Twitter use from embedded applications or in other environments in which
it is not possible to use the existing oauth flows because there is no
way to bring up a browser. It in no way prevents or discourages use of
the existing oauth flows in scenarios where a browser is available.

Really, the current lack of oauth delegation is a far bigger obstacle to
being able to say "don't give your Twitter password to anyone else" than
the ability to turn a username/password into oauth credentials will ever
be.

--
Dave Sherohman

[Abraham Williams]

On Fri, Dec 11, 2009 at 00:53, Dave Sherohman <da...@fishtwits.com> wrote:

- If oauth is the only allowed authentication method, a rogue app would
 not be able to gain full access to your account.  Perhaps most
 importantly, it would not be capable of changing your password and
 locking you out.

Currently this is not true. http://code.google.com/p/twitter-api/issues/detail?id=1012

--
Abraham Williams | Community Evangelist | http://web608.org
Project | Intersect | http://intersect.labs.poseurtech.com
Hacker | http://abrah.am | http://twitter.com/abraham
This email is: [ ] shareable [x] ask first [ ] private.
Sent from Madison, WI, United States

[Dave Sherohman]

On Fri, Dec 11, 2009 at 01:27:48AM -0600, Abraham Williams wrote:
> On Fri, Dec 11, 2009 at 00:53, Dave Sherohman <da...@fishtwits.com> wrote:
> > - If oauth is the only allowed authentication method, a rogue app would
> > not be able to gain full access to your account. Perhaps most
> > importantly, it would not be capable of changing your password and
> > locking you out.
> >
>
> Currently this is not true.
> http://code.google.com/p/twitter-api/issues/detail?id=1012

Hrm. Didn't know about that one. In that case, amend my quoted
statement to replace both occurrences of "would not" with "should not".
:p

--
Dave Sherohman

[Duane Roelands]

> It seems clear to me from Raffi's
> comments on it that this third oauth flow is intended solely to enable
> Twitter use from embedded applications or in other environments in which
> it is not possible to use the existing oauth flows because there is no
> way to bring up a browser.

And this will be enforced...how? The API is going to be smart enough
to discern the "environment" from which the request originates? Of
course not. The methods that allow the user-credentials-for-OAuth-
tokens swap will be available to all developers. Developers who want
the easier implementation and easier user experience will choose those
methods, amplifying the notion that giving away your Twitter
credentials to third-party apps is a good idea.

> It in no way prevents or discourages use of the existing oauth flows in scenarios where a browser is available.

Prevents? No. Discourages? Absolutely. It provides an incentive
for poor security decisions by developers and users.

[Dave Sherohman]

On Fri, Dec 11, 2009 at 04:03:01AM -0800, Duane Roelands wrote:
> >�It seems clear to me from Raffi's

> > comments on it that this third oauth flow is intended solely to enable
> > Twitter use from embedded applications or in other environments in which
> > it is not possible to use the existing oauth flows because there is no
> > way to bring up a browser.
>
> And this will be enforced...how?

The same way that oauth usage is enforced today: By attempting to
educate users that they should not provide their login credentials to
third-party websites.

> Developers who want the easier implementation and easier user
> experience will choose those methods,

As noted in my earlier message, I dispute your assertion that "type in
name, remember password, type in password" (even without an intermediate
"try to remember which password was for Twitter, enter a couple
incorrect and/or typoed attempts, give up, go find the piece of paper
where password is written down" phase) is an "easier user experience"
than "click, click, click, done".

Again, I grant that "enter username and password" is more familiar from
long use, but it is not actually easier.

In my experience (both as a developer and as a sysadmin), users prefer
authentication methods which do not require them to remember or locate
credentials. They often initially resist these "alternative" methods
due to unfamiliarity, but, once they've done it enough times that they
no longer have to think about how to carry out each step, they are
highly resistant to going back to more "traditional" authentication
methods which require them to do more work to log in. The fact that
methods exist which remove this extra work while also being more secure
is just gravy for those of us who are concerned with such things.

Once users are accustomed to the ease of passwordless oauth login from
one site, I fully expect them to want that same convenience on other
sites. I further expect that this is already happening as users find
that the existing web-based oauth flow is easier for them than basic
auth.

(The exception to these comments is in the case where oauth fails to
work properly, which can be intensely frustrating for users. However,
this is much less commmon now than it was even three months ago and,
more importantly, by allowing Twitter to focus exclusively on oauth, I
expect that replacing basic auth with this third oauth flow will lead to
increased reliability of *all* oauth flows.)

> > It in no way prevents or discourages use of the existing oauth flows
> > in scenarios where a browser is available.
>
> Prevents? No. Discourages? Absolutely. It provides an incentive
> for poor security decisions by developers and users.

Lazy developers will always take the easy way out, sure, and that's
generally going to be less secure. But I'm still not seeing any
coherent argument for how the planned third oauth flow will, in any way,
be *worse* than the existing basic auth scheme. It may not be an
absolutely perfect world in which absolutely nothing except Twitter
itself is capable of accepting a Twitter password, but it's still a big
improvement on what we have today.

--
Dave Sherohman

[Swap]

Couldn't agree more. If this is true, it's time for me to say goodbye.

[SM]

I agree with Isaiah. This is a huge improvement over the current PIN
workflow.

When will this roll out? Is there an authorization endpoint we can use
now for testing purposes? That would be great.

On Dec 10 2009, 8:58 am, Isaiah <supp...@yourhead.com> wrote:
> This seems like a dramatic improvement to me.  When will Twitter start rolling out support for this, I'd like to be ready with something on github for this as soon as it lands.
>
> Isaiah
>
> YourHead Software

> supp...@yourhead.comhttp://www.yourhead.com

>
> On Dec 10, 2009, at 5:22 AM, Raffi Krikorian wrote:
>
> > we're not making any fundamental changes to oauth - your apps should
> > continue to work fine.
>
> > the changes that we are making involve implementing

> >http://tools.ietf.org/html/draft-dehora-farrell-oauth-accesstoken-cre....

> > this will allow applications to obtain oauth tokens for a user given
> > the user's username / password.
>