4 ms·

Exactly OAuth works well on the web when the requesting application doesn't have control of the browser. In any situation where the requesting application cont

• pyre 15y ago
  The alternative is to display the Twitter URL that the user must go to to authorize the app. Then have them copy-paste the credentials back into the app. I.e.: Go to this url to authorize app: http://twitter.com/auth?token=blah Please input credentials: [__________]
  • chopsueyar 15y ago
    Most. Successful. App. Ever.
  • darklajid 15y ago
    I like this idea. At least this way copy and paste would finally be a hard mobile platform requirement, to be able to support Twitter/OAuth. No - I'm not serious. The idea is horrible..
• joe_the_user 15y ago
  Wait! But my point is that Oauth doesn't work for security against malicious apps any--fricken--where. Not on the desktop, not on the web, NOWHERE. The model of one web page opening another web page "for your convenience" is the model of bank phishing spam attacks. You don't control the browser if another page has opened the browser for you. And unless my research terribly misguided, Oauth absolutely requires the initial app's web page to be the actor which opens the authorization page (Oauth 1.1 requires the whole 'handshake' process to happen fairly quickly for God-knows-what-pseudo-security-reason). What's the user's reaction to entering credentials to twitterauthorizationtimstamp.com? "Sure, that makes sense..." Oauth is like "electronic checks" signed with Photoshop - its a fig leaf of security. It's not entirely bad but it certainly doesn't deliver what it sort-of seems to be trying to deliver.