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)
