OAuth and screen name

[djMax]

Sorry if this is a noob question, but how can we verify the
screen_name of an OAuth token? It would seem that having it only out
of band as a query arg means it's subject to spoofing right? Not sure
how I build secure site login with the core identifier may not match
the token I'm given.

[Matt Sanford]

Hi there,

I recommend calling verify_credentials with your new token to
verify the user in question. The screen_name was added as a
convenience method because there were a great many complaints about
have to do yet another round trip for the screen_name.

Thanks;
— Matt Sanford

[Dossy Shiobara]

Right, that's why I keep saying that the callback URL needs to be signed
... so the consumer can protect against tampering of the request.

--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
Panoptic Computer Network | http://panoptic.com/
"He realized the fastest way to change is to laugh at your own
folly -- then you can let go and quickly move on." (p. 70)

[djMax]

Ok got it. This explains more. So when I call authenticate (rather
than authorize) I get back the original oauth_token I was given in
authorize. The thing I'm not getting is how is this authenticated?
Anybody could find this token somewhere and then just become the user
in question right?

[Abraham Williams]

the oauth_token you are returned is only good for getting an access token from oauth/access_token. that access token is what lets you act as the user.

--
Abraham Williams | http://the.hackerconundrum.com
Hacker | http://abrah.am | http://twitter.com/abraham
Web608 | Community Evangelist | http://web608.org
This email is: [ ] blogable [x] ask first [ ] private.
Sent from Madison, Wisconsin, United States

[Dossy Shiobara]

On 4/16/09 6:02 PM, Abraham Williams wrote:
> the oauth_token you are returned is only good for getting an access
> token from oauth/access_token. that access token is what lets you act as
> the user.

Wait, what? The oauth_token that's returned from the
_oauth/authenticate_ method is already an Access Token, for which you
don't have the secret to.

I'm hoping Twitter fixes this somehow.

[Abraham Williams]

I actually miss read djMix and just saw "authorize" and not "authenticate". That being said when I was testing oauth/authenticate a few days ago I used the *exact* same code for both oauth/authorize and oauth/authenticate and both worked implying a return of a request token. It is possible that I was not paying attention and was using access tokens from an older session though. I'll double check later tonight.

Abraham

[djMax]

I'm not sure you don't have the secret for it. I'm still trying to
understand the tweet# code, but you were supposed to have saved the
"new" secret for that token when you got the original request token
right? Right now when trying to exchange that secondary oauth_token
for an access token, tweet# isn't passing a secret.

[Abraham Williams]

So my testing before was wrong somehow. I think I was not setting a callback url and was getting sent to production where I had a valid session already going.

They correct flow is:
1) get request token from twitter.
2) send user to twitter with oauth_token for the first time.
3) user returns and app uses request token to get user access token which get stored.
4) user come back to site to sign in and is not signed in.
5) site gets request token from twitter.
6) user is sent to twitter with request oauth_token and are automatically redirected back to site.
7) access oauth_token is returned with user which can be matched with oauth_token_secret stored in the database.

It seems like it would make more sense to use the same work flow for both oauth/authorize and oauth/authenticate. Then the same code could be used in the callback function and the authenticate method would be more secure.

Sorry about all the misinformation.
Abraham

[John Kristian]

It would make more sense to me, too, to use the same protocol flow for
oauth/authorize and /authenticate.

[Dossy Shiobara]

On 4/17/09 2:51 AM, Abraham Williams wrote:
> They correct flow is:
> 1) get request token from twitter.
> 2) send user to twitter with oauth_token for the first time.

Send the user to Twitter how, though? oauth/authorize? How do you know
if this is the user's first time or not?

> 3) user returns and app uses request token to get user access token
> which get stored.

This is fine, unless the user returns with an access token and not the
original request token. This is what currently happens with
oauth/authenticate.

> 4) user come back to site to sign in and is not signed in.
> 5) site gets request token from twitter.
> 6) user is sent to twitter with request oauth_token and are
> automatically redirected back to site.
> 7) access oauth_token is returned with user which can be matched with
> oauth_token_secret stored in the database.

This would work fine, assuming in step #2 you had some way of knowing
whether a Twitter user had never previously OAuth authorized your app.

[djMax]

I believe this flow is not secure (or not "as" secure) because that
URL that is "transmitted" via the browser is permanently reusable by
anyone to login to my service as that twitter user. In the
authorization flow, I don't believe any such URL ever goes through the
browser.

So basically I think the Twitter folks need to change the last step in
the flow to be an exchange of a request token to the original access
token by the app on the backend...

[Abraham Williams]

On Fri, Apr 17, 2009 at 07:01, Dossy Shiobara <do...@panoptic.com> wrote:

On 4/17/09 2:51 AM, Abraham Williams wrote:

They correct flow is:
1) get request token from twitter.
2) send user to twitter with oauth_token for the first time.

Send the user to Twitter how, though?  oauth/authorize?  How do you know if this is the user's first time or not?

Either/Or.
 

3) user returns and app uses request token to get user access token
which get stored.

This is fine, unless the user returns with an access token and not the original request token.  This is what currently happens with oauth/authenticate.

If they previously authorized and authenticate was used you would have to check the beginning of the oauth_token string for the user_id.
 

4) user come back to site to sign in and is not signed in.
5) site gets request token from twitter.
6) user is sent to twitter with request oauth_token and are
automatically redirected back to site.
7) access oauth_token is returned with user which can be matched with
oauth_token_secret stored in the database.

This would work fine, assuming in step #2 you had some way of knowing whether a Twitter user had never previously OAuth authorized your app.

--
Dossy Shiobara              | do...@panoptic.com | http://dossy.org/

Panoptic Computer Network   | http://panoptic.com/
 "He realized the fastest way to change is to laugh at your own
   folly -- then you can let go and quickly move on." (p. 70)

[Matt Sanford]

Hello again,

    Let me be more specific that my previous mails. This will be changing. Let me emphasize that:

⚠ The new authenticate method will be changing in a way that breaks the current behavior.

    At this point it is only a matter of time until I can get the new code reviewed and deployed. I would suggest people hold off on the authenticate method for the moment. I'll send more details once the code is reviewed and we're sure it won't be delayed for some reason.

Thanks;

  — Matt Sanford

[djMax]

You're such a tease! I'm assuming that it's going to change by you
returning a request token and us exchanging it for the previous access
token like usual... I understand you're probably not going to respond
to that.

(as an aside, we've implemented this in dev with a fallback so that if
the authenticate fails or returns unusable results, we just try
authorize instead)

[Chris Messina]

I'm going to bring this up just to put this out there, but it really
seems to me that you should be using OpenID to authenticate the user
and OAuth for authorizing access to a user's account.

Given that any user can change their username at will, I worry that
app developers will rely on and *trust* the username provided by
Twitter when in fact that's really not what should be happening.

Perhaps this isn't the thread for it, but it seems to me that Twitter
should strongly consider adopting OpenID for authentication rather
than jerry-rigging it with OAuth.

I posted this concern to the OAuth list for discussion:

http://groups.google.com/group/oauth/browse_thread/thread/583720b6cc447e7b

Eran Hammer (author of the OAuth spec) also weighed in, in support of
Twitter's approach:

http://www.hueniverse.com/hueniverse/2009/04/twitter-connect.html

Chris

[Matt Sanford]

Hello all,

    Totally right, we just deployed the change. The method now calls the callback with the request token and that token can be exchanged for the existing access token. I have been away from email getting the fix tested and deployed or I would have responded sooner. This fixes the major issue (token guessing) there are still a few side issues that we need to hash out. The main ones being:

 • As a convenience we provide screen_name and user_id … these could be changed on a URL via a man-in-the-middle. An easy fix it to take away the convenience and go back to making people call verify_credentials. In all likelihood we'll end up having to do that. 

 • A man-in-the-middle could change any other URL parameters during the redirect back to the application. That URL information is not signed in any way.

 • This all seems to be very close to what OpenID offers. I've been siding with Eran [1] but we may find compelling reasons to add OpenID support in the future. We simply don't have the man-power to review what's needed for OpenID and implement it right now.

Thanks;

  — Matt Sanford / @mzsanford

[1] - http://www.hueniverse.com/hueniverse/2009/04/twitter-connect.html

[Dossy Shiobara]

On 4/17/09 4:58 PM, Matt Sanford wrote:
> Totally right, we just deployed the change. The method now calls the
> callback with the request token and that token can be exchanged for
> the existing access token.

OMG awesome! Thank you SO much for the quick turn-around, Matt.

Now, can someone help investigate why I keep getting HTTP 500 responses
to my OAuth requests? (FYI, HTTP Basic Auth requests for the same users
succeed just fine.)

[Matt Sanford]

Hi Dossy,

    It's working fine for me, and it sounds like for Abraham as well. Perhaps some more details about how you're calling it would help. Go ahead and fill out a bug report [1] with the headers and whatnot and I'll take a look.

Thanks;

  — Matt

[1] - http://code.google.com/p/twitter-api/issues/entry

[Dossy Shiobara]

On 4/17/09 5:28 PM, Matt Sanford wrote:
> It's working fine for me, and it sounds like for Abraham as well.
> Perhaps some more details about how you're calling it would help. Go
> ahead and fill out a bug report [1] with the headers and whatnot and
> I'll take a look.

Done! Thanks.

http://code.google.com/p/twitter-api/issues/detail?id=478

[Doug Williams]

Matt has done an amazing job this week. Just want to throw it out there that I'm super impressed.

Now... to drop Sign in with Twitter around the web.

Doug Williams
Twitter API Support
http://twitter.com/dougw

[Petermdenton]

Yeah Matt's the Donald Trump of releases. He looks a task or bug, right in the eye, points:

"you're fired." 

[Dossy Shiobara]

On 4/17/09 7:19 PM, Doug Williams wrote:
> Matt has done an amazing job this week. Just want to throw it out there
> that I'm super impressed.
>
> Now... to drop Sign in with Twitter around the web.

It's now available on Twitter Karma! I'm still allowing folks to use
their Twitter user/password and HTTP Basic Auth. just in case, but it's
there.

Matt, you really kicked ass this week w/ OAuth. Thanks!