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 On Apr 17, 8:10 am, Matt Sanford <m...@twitter.com> wrote: > 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 > > On Apr 17, 2009, at 06:26 AM, djMax wrote: > > > > > > > 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... > > > On Apr 17, 8:01 am, 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? > > >>> 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. > > >> -- > >> 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)
