What's up with OAuth?

207 views
Skip to first unread message

Raffi Krikorian

unread,
Feb 11, 2010, 10:18:16 PM2/11/10
to twitter-deve...@googlegroups.com, twitter-ap...@googlegroups.com
hi all.

this is a long overdue e-mail, but i wanted to tease out some of the directions that Twitter is going with OAuth.  i want to touch upon four topics: delegation, OAuth WRAP/2.0, username/password OAuth token exchange, and basic authentication deprecation.

DELEGATION - OAuth Echo

twitter users love posting media on third-party sites, and delegation in identity verification is one of the major hurdles for an OAuth-enabled twitter client to succeed.  i started a series of blog posts around the following problem:

You're an OAuth enabled Twitter client, and you've already authorized your user.  Your user wants to use a media providing service like TwitPic.  TwitPic, currently, asks for the username and password of your user so it can store the photo on behalf of the Twitter user.  You don't have that username and password, so how do you give the ability to TwitPic to verify the identity of your user?

check out the proposal for what we're calling "OAuth Echo" at http://mehack.com/OAuth-echo-delegation-in-identity-verificatio.  please feel free to comment there, or on the twitter development talk mailing list (or, even just reach out to me directly).  i think this experiment in engaging the community around designing this security/identity workflow has been definitely a success, and i feel we're rapidly converging on a solution for identity verification delegation.  in parallel, we're going to start the process to engage our media providers in the conversation as well, and we're hopeful we can move this forward quickly.

OAUTH WRAP/2.0

OAuth is evolving, and we at Twitter are keeping up with it.  that being said, we're keeping our eyes on OAuth WRAP and OAuth 2.0. we like a lot about it:
  • it requires the use of SSL;
  • there is no custom signing mechanism -- you simply pass us a token, and that token is secured by SSL; and 
  • it formalizes a bunch of "profiles" that we've been actively thinking about (e.g. a username/password exchange)
in general, we really like WRAP/2.0 because it's just so easy to implement from the client side.  there are no longer questions around creating the proper signature base string, etc.  we're sure that developers will like it as well.  we've started work on an internal implementation of OAuth WRAP and we envision that we'll simultaneously support both OAuth 1.0a and WRAP/2.0 for a while.  our hope is to get WRAP out the door soon (and before we finally deprecate basic authentication).

USERNAME/PASSWORD TO OAUTH TOKEN EXCHANGE - xAuth

@rsarver and @noradio announced that we are going to support a mechanism where a username and a password can be directly exchanged for an OAuth token and secret -- we're calling this xAuth.  if you've been watching the mailing list, Seesmic Look has been a beta partner in testing xAuth exchange (and @abraham has already detailed how it works).  

because we're moving everybody off basic authentication, we originally envisioned this as a mechanism for developers to exchange all the username and passwords they have in their databases for OAuth tokens en masse.  that's still one of our use cases.  another use case is around environments where software can't bring up a web browser (e.g. set top boxes, game consoles, embedded devices).  we want to support those as well.

you're going to have to apply to get access to this exchange mechanism (by sending e-mail to a...@twitter.com), but, in general, all applications except web applications will get access.  we feel that the xAuth exchange allows for the best mix of security and user experience for desktop and possibly mobile applications.  web applications will simply have to use OAuth as it was designed, and send their users through the web flow.

BASIC AUTHENTICATION DEPRECATION

yup - it's still happening.  we're targeting June 2010.  everybody, including legacy applications, will have to move over.

for those who are building new applications, use OAuth.  save yourself the transition time later, and start thinking about it now.  for those who have applications already out there, it would be really beneficial to start thinking about a migration path right now and we're here to help.  if you need it, please feel free to reach out to us and we'll help you figure out what you need to do. 

to help entice you over, as you know:
  • we have increased rate limits on api.twitter.com to those who are using OAuth (350 calls to the REST API per hour -- and increasing towards 1500/hour); and
  • (as some of you are painfully aware) you can only set a source parameter with OAuth calls to status/update.
we know some of you think there are hurdles in places to converting over to OAuth -- suffice it to say, we're actively trying to address them.  some potential hurdles are mentioned in this e-mail, and if you think there are more then please feel free to reach out to us.  again, we really want to make this switch-over easy for everybody.


thanks!  and, as always - feel free to reach out to us anytime here, or to @twitterapi.

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

kehers

unread,
Feb 11, 2010, 11:12:51 PM2/11/10
to Twitter Development Talk
Talking xAuth, hope mobile apps count as 'applications except web
applications'

Raffi Krikorian

unread,
Feb 11, 2010, 11:29:26 PM2/11/10
to twitter-deve...@googlegroups.com
yup - they do :)


On Thu, Feb 11, 2010 at 8:12 PM, kehers <keh...@gmail.com> wrote:
Talking xAuth, hope mobile apps count as 'applications except web
applications'



Cameron Kaiser

unread,
Feb 11, 2010, 11:30:59 PM2/11/10
to twitter-deve...@googlegroups.com
> > Talking xAuth, hope mobile apps count as 'applications except web
> > applications'
>
> yup - they do :)

Already signed up (I think) for u/p -> OAuth Token. WRAPped, even better.

--
------------------------------------ personal: http://www.cameronkaiser.com/ --
Cameron Kaiser * Floodgap Systems * www.floodgap.com * cka...@floodgap.com
-- New political correctness is but old fascism writ large. -- Dr Digby James -

Ryan Alford

unread,
Feb 11, 2010, 11:36:13 PM2/11/10
to twitter-deve...@googlegroups.com

He specifically states the possibility for mobile apps to use xAuth.

Ryan

Sent from my DROID

Ivan

unread,
Feb 12, 2010, 12:01:50 AM2/12/10
to Twitter Development Talk
This is good news. This has taken ages to solve though. We came up
with a solution at Tipjoy, told everyone about it, but no one
bothered. Clients are largely to blame for the continued commonness of
asking for passwords:
http://tipjoy.com/api/#authentication

Ivan
http://kirigin.com

janole

unread,
Feb 12, 2010, 4:57:11 AM2/12/10
to Twitter Development Talk
Hi Raffi,

I can't express how happy I am about xAuth. That'll solve most of the
problems I've envisioned with using OAuth in my S60 Twitter client
'Gravity'.

Now, I've had a quick look at how Seesmic Look does the authentication
process and I've got two questions:

1.) Will it be possible to run the xAuth authentication over a HTTP
proxy? It looks like it's possible at first glance. I've got a lot of
users from countries where Twitter is blocked and it would be crucial
for them to run through an "API proxy."

2.) Is SSL absolutely mandatory for retrieving the access token? The
reason for this question is that I've got quite a number of users
which cannot use SSL (due to misconfigured network operator HTTP
proxies.) Gravity is using SSL by default, but once it detects a
problem with using SSL, it will "fallback" to plain HTTP.

Cheers & thanks for coming up with xAuth! :-)
Ole

--
Jan Ole Suhr
su...@mobileways.de
http://twitter.com/janole


On 12 Feb., 04:18, Raffi Krikorian <ra...@twitter.com> wrote:
> hi all.
>
> this is a long overdue e-mail, but i wanted to tease out some of the
> directions that Twitter is going with OAuth.  i want to touch upon four
> topics: delegation, OAuth WRAP/2.0, username/password OAuth token exchange,
> and basic authentication deprecation.
>

> *DELEGATION - OAuth Echo*


>
> twitter users love posting media on third-party sites, and delegation in
> identity verification is one of the major hurdles for an OAuth-enabled
> twitter client to succeed.  i started a series of blog posts around the
> following problem:
>
> You're an OAuth enabled Twitter client, and you've already authorized your
>
> > user.  Your user wants to use a media providing service like TwitPic.
> >  TwitPic, currently, asks for the username and password of your user so it
> > can store the photo on behalf of the Twitter user.  You don't have that
> > username and password, so how do you give the ability to TwitPic to verify
> > the identity of your user?
>

> check out the proposal for what we're calling "OAuth Echo" athttp://mehack.com/OAuth-echo-delegation-in-identity-verificatio.  please


> feel free to comment there, or on the twitter development talk mailing

> list<http://groups.google.com/group/twitter-development-talk>(or, even


> just reach out to me directly).  i think this experiment in
> engaging the community around designing this security/identity workflow has
> been definitely a success, and i feel we're rapidly converging on a solution
> for identity verification delegation.  in parallel, we're going to start the
> process to engage our media providers in the conversation as well, and we're
> hopeful we can move this forward quickly.
>

> *OAUTH WRAP/2.0*


>
> OAuth is evolving, and we at Twitter are keeping up with it.  that being
> said, we're keeping our eyes on OAuth WRAP and OAuth

> 2.0<http://wiki.oauth.net/OAuth-WRAP>.


> we like a lot about it:
>

>    - it requires the use of SSL;
>    - there is no custom signing mechanism -- you simply pass us a token, and


>    that token is secured by SSL; and

>    - it formalizes a bunch of "profiles" that we've been actively thinking


>    about (e.g. a username/password exchange)
>

> in general, we really like WRAP/2.0 because it's just *so* easy to implement


> from the client side.  there are no longer questions around creating the
> proper signature base string, etc.  we're sure that developers will like it
> as well.  we've started work on an internal implementation of OAuth WRAP and
> we envision that we'll simultaneously support both OAuth 1.0a and WRAP/2.0
> for a while.  our hope is to get WRAP out the door soon (and before we
> finally deprecate basic authentication).
>

> *USERNAME/PASSWORD TO OAUTH TOKEN EXCHANGE - xAuth*


>
> @rsarver and @noradio announced that we are going to support a mechanism
> where a username and a password can be directly exchanged for an OAuth token
> and secret -- we're calling this xAuth.  if you've been watching the mailing

> list, Seesmic Look <http://seesmic.com/look> has been a beta partner in


> testing xAuth exchange (and @abraham has already detailed how it

> works<http://the.hackerconundrum.com/2010/02/sneak-peek-at-twitters-browser...>).


>
> because we're moving everybody off basic authentication, we originally
> envisioned this as a mechanism for developers to exchange all the username
> and passwords they have in their databases for OAuth tokens en masse.
>  that's still one of our use cases.  another use case is around environments
> where software can't bring up a web browser (e.g. set top boxes, game
> consoles, embedded devices).  we want to support those as well.
>
> you're going to have to apply to get access to this exchange mechanism (by
> sending e-mail to a...@twitter.com), but, in general, all applications except
> web applications will get access.  we feel that the xAuth exchange allows
> for the best mix of security and user experience for desktop and possibly
> mobile applications.  web applications will simply have to use OAuth as it
> was designed, and send their users through the web flow.
>

> *BASIC AUTHENTICATION DEPRECATION*


>
> yup - it's still happening.  we're targeting June 2010.  everybody,
> including legacy applications, will have to move over.
>
> for those who are building new applications, use OAuth.  save yourself the
> transition time later, and start thinking about it now.  for those who have
> applications already out there, it would be really beneficial to start
> thinking about a migration path right now and we're here to help.  if you
> need it, please feel free to reach out to us and we'll help you figure out
> what you need to do.
>
> to help entice you over, as you know:
>

>    - we have increased rate limits on api.twitter.com to those who are using


>    OAuth (350 calls to the REST API per hour -- and increasing towards
>    1500/hour); and

>    - (as some of you are painfully aware) you can only set a source

yegle

unread,
Feb 12, 2010, 6:42:23 AM2/12/10
to Twitter Development Talk
Hi Raffi,
Is xauth the same as the 5.3 Username and Password Profile in WRAP's
specification?

On Feb 12, 11:18 am, Raffi Krikorian <ra...@twitter.com> wrote:
> hi all.
>
> this is a long overdue e-mail, but i wanted to tease out some of the
> directions that Twitter is going with OAuth.  i want to touch upon four
> topics: delegation, OAuth WRAP/2.0, username/password OAuth token exchange,
> and basic authentication deprecation.
>

> *DELEGATION - OAuth Echo*


>
> twitter users love posting media on third-party sites, and delegation in
> identity verification is one of the major hurdles for an OAuth-enabled
> twitter client to succeed.  i started a series of blog posts around the
> following problem:
>
> You're an OAuth enabled Twitter client, and you've already authorized your
>
> > user.  Your user wants to use a media providing service like TwitPic.
> >  TwitPic, currently, asks for the username and password of your user so it
> > can store the photo on behalf of the Twitter user.  You don't have that
> > username and password, so how do you give the ability to TwitPic to verify
> > the identity of your user?
>

> check out the proposal for what we're calling "OAuth Echo" athttp://mehack.com/OAuth-echo-delegation-in-identity-verificatio.  please


> feel free to comment there, or on the twitter development talk mailing

> list<http://groups.google.com/group/twitter-development-talk>(or, even


> just reach out to me directly).  i think this experiment in
> engaging the community around designing this security/identity workflow has
> been definitely a success, and i feel we're rapidly converging on a solution
> for identity verification delegation.  in parallel, we're going to start the
> process to engage our media providers in the conversation as well, and we're
> hopeful we can move this forward quickly.
>

> *OAUTH WRAP/2.0*


>
> OAuth is evolving, and we at Twitter are keeping up with it.  that being
> said, we're keeping our eyes on OAuth WRAP and OAuth

> 2.0<http://wiki.oauth.net/OAuth-WRAP>.


> we like a lot about it:
>

>    - it requires the use of SSL;
>    - there is no custom signing mechanism -- you simply pass us a token, and


>    that token is secured by SSL; and

>    - it formalizes a bunch of "profiles" that we've been actively thinking


>    about (e.g. a username/password exchange)
>

> in general, we really like WRAP/2.0 because it's just *so* easy to implement


> from the client side.  there are no longer questions around creating the
> proper signature base string, etc.  we're sure that developers will like it
> as well.  we've started work on an internal implementation of OAuth WRAP and
> we envision that we'll simultaneously support both OAuth 1.0a and WRAP/2.0
> for a while.  our hope is to get WRAP out the door soon (and before we
> finally deprecate basic authentication).
>

> *USERNAME/PASSWORD TO OAUTH TOKEN EXCHANGE - xAuth*


>
> @rsarver and @noradio announced that we are going to support a mechanism
> where a username and a password can be directly exchanged for an OAuth token
> and secret -- we're calling this xAuth.  if you've been watching the mailing

> list, Seesmic Look <http://seesmic.com/look> has been a beta partner in


> testing xAuth exchange (and @abraham has already detailed how it

> works<http://the.hackerconundrum.com/2010/02/sneak-peek-at-twitters-browser...>).


>
> because we're moving everybody off basic authentication, we originally
> envisioned this as a mechanism for developers to exchange all the username
> and passwords they have in their databases for OAuth tokens en masse.
>  that's still one of our use cases.  another use case is around environments
> where software can't bring up a web browser (e.g. set top boxes, game
> consoles, embedded devices).  we want to support those as well.
>
> you're going to have to apply to get access to this exchange mechanism (by
> sending e-mail to a...@twitter.com), but, in general, all applications except
> web applications will get access.  we feel that the xAuth exchange allows
> for the best mix of security and user experience for desktop and possibly
> mobile applications.  web applications will simply have to use OAuth as it
> was designed, and send their users through the web flow.
>

> *BASIC AUTHENTICATION DEPRECATION*


>
> yup - it's still happening.  we're targeting June 2010.  everybody,
> including legacy applications, will have to move over.
>
> for those who are building new applications, use OAuth.  save yourself the
> transition time later, and start thinking about it now.  for those who have
> applications already out there, it would be really beneficial to start
> thinking about a migration path right now and we're here to help.  if you
> need it, please feel free to reach out to us and we'll help you figure out
> what you need to do.
>
> to help entice you over, as you know:
>

>    - we have increased rate limits on api.twitter.com to those who are using


>    OAuth (350 calls to the REST API per hour -- and increasing towards
>    1500/hour); and

>    - (as some of you are painfully aware) you can only set a source

Raffi Krikorian

unread,
Feb 12, 2010, 10:07:24 AM2/12/10
to twitter-deve...@googlegroups.com
Now, I've had a quick look at how Seesmic Look does the authentication
process and I've got two questions:

1.) Will it be possible to run the xAuth authentication over a HTTP
proxy? It looks like it's possible at first glance. I've got a lot of
users from countries where Twitter is blocked and it would be crucial
for them to run through an "API proxy."

i don't see why not, as long as the proxy can handle HTTPS connections...
 
2.) Is SSL absolutely mandatory for retrieving the access token? The
reason for this question is that I've got quite a number of users
which cannot use SSL (due to misconfigured network operator HTTP
proxies.) Gravity is using SSL by default, but once it detects a
problem with using SSL, it will "fallback" to plain HTTP.

unfortunately, as i see it now, xAuth will require SSL. 
 

Cheers & thanks for coming up with xAuth! :-)
Ole


np :P
 

Raffi Krikorian

unread,
Feb 12, 2010, 10:08:51 AM2/12/10
to twitter-deve...@googlegroups.com
similar idea, different implementation.  when we deploy WRAP/2.0, the corresponding profile would be the username/password profile.

Terence Eden

unread,
Feb 12, 2010, 6:47:04 AM2/12/10
to Twitter Development Talk
Will mobile OAuth be fixed for all users before this goes live?
See http://code.google.com/p/twitter-api/issues/detail?id=395 for
details.

tsmango

unread,
Feb 12, 2010, 9:14:25 AM2/12/10
to Twitter Development Talk
Just to clarify, xauth will be available to mobile applications (who
apply) going forward to authenticate users, not just a one time way to
exchange stored usernames and passwords?

On Feb 11, 10:18 pm, Raffi Krikorian <ra...@twitter.com> wrote:
> hi all.
>
> this is a long overdue e-mail, but i wanted to tease out some of the
> directions that Twitter is going with OAuth.  i want to touch upon four
> topics: delegation, OAuth WRAP/2.0, username/password OAuth token exchange,
> and basic authentication deprecation.
>

> *DELEGATION - OAuth Echo*


>
> twitter users love posting media on third-party sites, and delegation in
> identity verification is one of the major hurdles for an OAuth-enabled
> twitter client to succeed.  i started a series of blog posts around the
> following problem:
>
> You're an OAuth enabled Twitter client, and you've already authorized your
>
> > user.  Your user wants to use a media providing service like TwitPic.
> >  TwitPic, currently, asks for the username and password of your user so it
> > can store the photo on behalf of the Twitter user.  You don't have that
> > username and password, so how do you give the ability to TwitPic to verify
> > the identity of your user?
>

> check out the proposal for what we're calling "OAuth Echo" athttp://mehack.com/OAuth-echo-delegation-in-identity-verificatio.  please


> feel free to comment there, or on the twitter development talk mailing

> list<http://groups.google.com/group/twitter-development-talk>(or, even


> just reach out to me directly).  i think this experiment in
> engaging the community around designing this security/identity workflow has
> been definitely a success, and i feel we're rapidly converging on a solution
> for identity verification delegation.  in parallel, we're going to start the
> process to engage our media providers in the conversation as well, and we're
> hopeful we can move this forward quickly.
>

> *OAUTH WRAP/2.0*


>
> OAuth is evolving, and we at Twitter are keeping up with it.  that being
> said, we're keeping our eyes on OAuth WRAP and OAuth

> 2.0<http://wiki.oauth.net/OAuth-WRAP>.


> we like a lot about it:
>

>    - it requires the use of SSL;
>    - there is no custom signing mechanism -- you simply pass us a token, and


>    that token is secured by SSL; and

>    - it formalizes a bunch of "profiles" that we've been actively thinking


>    about (e.g. a username/password exchange)
>

> in general, we really like WRAP/2.0 because it's just *so* easy to implement


> from the client side.  there are no longer questions around creating the
> proper signature base string, etc.  we're sure that developers will like it
> as well.  we've started work on an internal implementation of OAuth WRAP and
> we envision that we'll simultaneously support both OAuth 1.0a and WRAP/2.0
> for a while.  our hope is to get WRAP out the door soon (and before we
> finally deprecate basic authentication).
>

> *USERNAME/PASSWORD TO OAUTH TOKEN EXCHANGE - xAuth*


>
> @rsarver and @noradio announced that we are going to support a mechanism
> where a username and a password can be directly exchanged for an OAuth token
> and secret -- we're calling this xAuth.  if you've been watching the mailing

> list, Seesmic Look <http://seesmic.com/look> has been a beta partner in


> testing xAuth exchange (and @abraham has already detailed how it

> works<http://the.hackerconundrum.com/2010/02/sneak-peek-at-twitters-browser...>).


>
> because we're moving everybody off basic authentication, we originally
> envisioned this as a mechanism for developers to exchange all the username
> and passwords they have in their databases for OAuth tokens en masse.
>  that's still one of our use cases.  another use case is around environments
> where software can't bring up a web browser (e.g. set top boxes, game
> consoles, embedded devices).  we want to support those as well.
>
> you're going to have to apply to get access to this exchange mechanism (by
> sending e-mail to a...@twitter.com), but, in general, all applications except
> web applications will get access.  we feel that the xAuth exchange allows
> for the best mix of security and user experience for desktop and possibly
> mobile applications.  web applications will simply have to use OAuth as it
> was designed, and send their users through the web flow.
>

> *BASIC AUTHENTICATION DEPRECATION*


>
> yup - it's still happening.  we're targeting June 2010.  everybody,
> including legacy applications, will have to move over.
>
> for those who are building new applications, use OAuth.  save yourself the
> transition time later, and start thinking about it now.  for those who have
> applications already out there, it would be really beneficial to start
> thinking about a migration path right now and we're here to help.  if you
> need it, please feel free to reach out to us and we'll help you figure out
> what you need to do.
>
> to help entice you over, as you know:
>

>    - we have increased rate limits on api.twitter.com to those who are using


>    OAuth (350 calls to the REST API per hour -- and increasing towards
>    1500/hour); and

>    - (as some of you are painfully aware) you can only set a source

Raffi Krikorian

unread,
Feb 12, 2010, 11:14:16 AM2/12/10
to twitter-deve...@googlegroups.com
yup - we're actively working on a fix for the mobile oauth pages (as well as a complete redesign of the oauth pages in general).

Raffi Krikorian

unread,
Feb 12, 2010, 11:15:23 AM2/12/10
to twitter-deve...@googlegroups.com
yup!  that's the plan.  sorry if it wasn't clear in the e-mail blast.

Raffi Krikorian

unread,
Feb 12, 2010, 11:15:56 AM2/12/10
to twitter-deve...@googlegroups.com
if, of course, you mean a mobile native application, and not a mobile web application.  mobile web applications still need to send their users through the regular oauth workflow.

tsmango

unread,
Feb 12, 2010, 12:04:55 PM2/12/10
to Twitter Development Talk, Raffi Krikorian
Yep, I meant mobile native applications. This is really a wonderful
idea! Very, very happy about this!

Isaiah Carew

unread,
Feb 12, 2010, 2:45:15 PM2/12/10
to twitter-deve...@googlegroups.com

so excited about xAuth.  i think this is really going to change the landscape in a big way.
can't wait to get going.
sent a message to a...@twitter.com -- that's all that's necessary to get going right?

thanks again,
isaiah

Norio Nomura

unread,
Feb 12, 2010, 8:52:59 PM2/12/10
to Twitter Development Talk
Hi,

I tested xAuth with below codes,
http://github.com/norio-nomura/ntlniph/tree/xAuth
and succeeded.

I want to know about xAuth's current status and roadmap.

Thanks,

--
Norio Nomura

On 2月12日, 午後12:18, Raffi Krikorian <ra...@twitter.com> wrote:
> hi all.
>
> this is a long overdue e-mail, but i wanted to tease out some of the
> directions that Twitter is going with OAuth.  i want to touch upon four
> topics: delegation, OAuth WRAP/2.0, username/password OAuth token exchange,
> and basic authentication deprecation.
>

> *DELEGATION - OAuth Echo*


>
> twitter users love posting media on third-party sites, and delegation in
> identity verification is one of the major hurdles for an OAuth-enabled
> twitter client to succeed.  i started a series of blog posts around the
> following problem:
>
> You're an OAuth enabled Twitter client, and you've already authorized your
>
> > user.  Your user wants to use a media providing service like TwitPic.
> >  TwitPic, currently, asks for the username and password of your user so it
> > can store the photo on behalf of the Twitter user.  You don't have that
> > username and password, so how do you give the ability to TwitPic to verify
> > the identity of your user?
>

> check out the proposal for what we're calling "OAuth Echo" athttp://mehack.com/OAuth-echo-delegation-in-identity-verificatio.  please


> feel free to comment there, or on the twitter development talk mailing

> list<http://groups.google.com/group/twitter-development-talk>(or, even


> just reach out to me directly).  i think this experiment in
> engaging the community around designing this security/identity workflow has
> been definitely a success, and i feel we're rapidly converging on a solution
> for identity verification delegation.  in parallel, we're going to start the
> process to engage our media providers in the conversation as well, and we're
> hopeful we can move this forward quickly.
>

> *OAUTH WRAP/2.0*


>
> OAuth is evolving, and we at Twitter are keeping up with it.  that being
> said, we're keeping our eyes on OAuth WRAP and OAuth

> 2.0<http://wiki.oauth.net/OAuth-WRAP>.


> we like a lot about it:
>

>    - it requires the use of SSL;
>    - there is no custom signing mechanism -- you simply pass us a token, and


>    that token is secured by SSL; and

>    - it formalizes a bunch of "profiles" that we've been actively thinking


>    about (e.g. a username/password exchange)
>

> in general, we really like WRAP/2.0 because it's just *so* easy to implement


> from the client side.  there are no longer questions around creating the
> proper signature base string, etc.  we're sure that developers will like it
> as well.  we've started work on an internal implementation of OAuth WRAP and
> we envision that we'll simultaneously support both OAuth 1.0a and WRAP/2.0
> for a while.  our hope is to get WRAP out the door soon (and before we
> finally deprecate basic authentication).
>

> *USERNAME/PASSWORD TO OAUTH TOKEN EXCHANGE - xAuth*


>
> @rsarver and @noradio announced that we are going to support a mechanism
> where a username and a password can be directly exchanged for an OAuth token
> and secret -- we're calling this xAuth.  if you've been watching the mailing

> list, Seesmic Look <http://seesmic.com/look> has been a beta partner in


> testing xAuth exchange (and @abraham has already detailed how it

> works<http://the.hackerconundrum.com/2010/02/sneak-peek-at-twitters-browser...>).


>
> because we're moving everybody off basic authentication, we originally
> envisioned this as a mechanism for developers to exchange all the username
> and passwords they have in their databases for OAuth tokens en masse.
>  that's still one of our use cases.  another use case is around environments
> where software can't bring up a web browser (e.g. set top boxes, game
> consoles, embedded devices).  we want to support those as well.
>
> you're going to have to apply to get access to this exchange mechanism (by
> sending e-mail to a...@twitter.com), but, in general, all applications except
> web applications will get access.  we feel that the xAuth exchange allows
> for the best mix of security and user experience for desktop and possibly
> mobile applications.  web applications will simply have to use OAuth as it
> was designed, and send their users through the web flow.
>

> *BASIC AUTHENTICATION DEPRECATION*


>
> yup - it's still happening.  we're targeting June 2010.  everybody,
> including legacy applications, will have to move over.
>
> for those who are building new applications, use OAuth.  save yourself the
> transition time later, and start thinking about it now.  for those who have
> applications already out there, it would be really beneficial to start
> thinking about a migration path right now and we're here to help.  if you
> need it, please feel free to reach out to us and we'll help you figure out
> what you need to do.
>
> to help entice you over, as you know:
>

>    - we have increased rate limits on api.twitter.com to those who are using


>    OAuth (350 calls to the REST API per hour -- and increasing towards
>    1500/hour); and

>    - (as some of you are painfully aware) you can only set a source

Dewald Pretorius

unread,
Feb 13, 2010, 10:44:52 AM2/13/10
to Twitter Development Talk
Raffi,

Could you please confirm that you've received my request for xauth?
The ticket number is 861418.

Because of that stupid Zendesk system, I cannot access the ticket
number that was sent back to me.

When you email something in, you don't see the ticket when you login
with your Twitter credentials, which is the only way to login to your
help desk.

jon

unread,
Feb 13, 2010, 10:44:37 AM2/13/10
to Twitter Development Talk
FYI, if anyone wants to get an to do a poor man's version of xAuth,
I'd written a script a few months ago to exchange credentials:

http://gist.github.com/108144

http://groups.google.com/group/twitter-development-talk/browse_thread/thread/2985c36158742455/6a179766f32f4d50#6a179766f32f4d50

- Jon


On Feb 12, 8:52 pm, Norio Nomura <norio.nom...@gmail.com> wrote:
> Hi,
>

> I tested xAuth with below codes,http://github.com/norio-nomura/ntlniph/tree/xAuth

Dewald Pretorius

unread,
Feb 13, 2010, 11:41:07 AM2/13/10
to Twitter Development Talk
Mmmm.... it looks as if you're scraping the pre-login Allow/Deny page.
That might just get your IP address blackholed.


On Feb 13, 11:44 am, jon <jonhoff...@gmail.com> wrote:
> FYI, if anyone wants to get an to do a poor man's version of xAuth,
> I'd written a script a few months ago to exchange credentials:
>
> http://gist.github.com/108144
>

> http://groups.google.com/group/twitter-development-talk/browse_thread...

jon

unread,
Feb 13, 2010, 5:47:52 PM2/13/10
to Twitter Development Talk
It worked for a one time oauth conversion for about 3000 accounts (i
ran a batch job across five processes and think it took an hour or so
to finish)-- however, that was back in may. the script was also
written pre oauth 1.0a, so there's no oauth_verifier. I'm not sure if
that's required now.

Ryan Alford

unread,
Feb 14, 2010, 8:40:01 AM2/14/10
to twitter-deve...@googlegroups.com

If I am not mistaken, the oauth_verifier is for the PIN.  So if you are not a desktop app, then its not required.

Ryan

Sent from my DROID

On Feb 14, 2010 1:04 AM, "jon" <jonho...@gmail.com> wrote:

It worked for a one time oauth conversion for about 3000 accounts (i
ran a batch job across five processes and think it took an hour or so
to finish)-- however, that was back in may.  the script was also
written pre oauth 1.0a, so there's no oauth_verifier. I'm not sure if
that's required now.


On Feb 13, 11:41 am, Dewald Pretorius <dpr...@gmail.com> wrote:

> Mmmm.... it looks as if you're sc...

Brian Smith

unread,
Feb 14, 2010, 5:57:13 PM2/14/10
to twitter-deve...@googlegroups.com
Raffi Krikorian wrote:
i think this experiment in engaging the community around designing this security/identity workflow has been definitely a success, and i feel we're rapidly converging on a solution for identity verification delegation.  in parallel, we're going to start the process to engage our media providers in the conversation as well, and we're hopeful we can move this forward quickly.
Could you explain how "OAuth Echo" works with OAuth WRAP/2.0?

Would it be possible for you to skip the OAuth 1.0a version of Echo and just deploy the WRAP/2.0 version? Otherwise, clients are going to get stuck with having to implement BOTH versions, as some delegators will surely implement only the OAuth 1.0a version, while others only implement the WRAP version. Similarly, delegators will probably feel pressure to support both versions, as some clients will only implement one or the other.

xAuth vs. the WRAP username/password profile is not such a big problem because client implements can just keep using Basic Auth until you support the WRAP username/password profile, and skip xAuth completely (unless they need to take advantage of the higher rate limits for xAuth).

in general, we really like WRAP/2.0 because it's just so easy to implement from the client side.  there are no longer questions around creating the proper signature base string, etc.  we're sure that developers will like it as well.  we've started work on an internal implementation of OAuth WRAP and we envision that we'll simultaneously support both OAuth 1.0a and WRAP/2.0 for a while.  our hope is to get WRAP out the door soon (and before we finally deprecate basic authentication).
Thanks,
Brian

Raffi Krikorian

unread,
Feb 14, 2010, 6:02:12 PM2/14/10
to twitter-deve...@googlegroups.com
Could you explain how "OAuth Echo" works with OAuth WRAP/2.0?

working on it -- expect to see another update on oauth echo on mehack tomorrow.
 
Would it be possible for you to skip the OAuth 1.0a version of Echo and just deploy the WRAP/2.0 version? Otherwise, clients are going to get stuck with having to implement BOTH versions, as some delegators will surely implement only the OAuth 1.0a version, while others only implement the WRAP version. Similarly, delegators will probably feel pressure to support both versions, as some clients will only implement one or the other.

its definitely something that we've considered.  i think, in reality, we're going to have to support both types as we don't yet have any notion on when/if we would deprecate oauth 1.0a -- in addition, not having oauth echo implemented for 1.0a, when we're pushing towards basic auth deprecation in june...  all in all, this seems too complicated to not have in our 1.0a implementation.
 
xAuth vs. the WRAP username/password profile is not such a big problem because client implements can just keep using Basic Auth until you support the WRAP username/password profile, and skip xAuth completely (unless they need to take advantage of the higher rate limits for xAuth).

the same goes with xAuth.
 

Shannon Whitley

unread,
Feb 17, 2010, 10:23:34 AM2/17/10
to Twitter Development Talk
Hi,

What is the expected wait time after submitting a request for xAuth
access?

I'm trying to let a client know how long the development cycle will
take, but a lot depends on this approval. My request is currently
pending from Thursday or Friday of last week.

Thank you.


Raffi Krikorian

unread,
Feb 17, 2010, 10:54:30 AM2/17/10
to twitter-deve...@googlegroups.com
we're in the process of putting the last pieces of infrastructure in place -- once that is in place, then the turnaround time on requests will be fairly quick.  right now, all requests are being logged, and will be responded to.
Reply all
Reply to author
Forward
0 new messages