6 ms·

Twitter’s Shit Sandwich

219 points by berberich 15y ago

tlrobinson 15y ago
As many others have pointed out, OAuth is extremely susceptible to phishing or snooping of passwords on platforms where the OAuth flow is done in an embedded web view, which can be considered "untrusted", vs. your browser which could be considered "trusted" because you know the URL bar is accurate, and there's no mechanism for 3rd parties to scrape passwords (well, except for user scripts / extensions) OAuth does also remove the burden of securely storing passwords, but so does xAuth.
- boucher 15y ago
  Of course, OAuth is also vulnerable to phishing in a "trusted" browser, when you're talking about average users who don't really understand how it works. One interesting way to provide "trust" would be to have a system wide "OAuth" view (or, "secure browser," or whatever you want to call it). It would have to contain some piece of user information, like say your user account name and photo, that the app itself is never granted access to. That way, if you're actually paying attention you can verify that the system displayed this view.
  - ableal 15y ago
    It would have to contain some piece of user information, like say your user account name and photo, that the app itself is never granted access to. A security seal, defined by the user (one time operation). Yahoo used to have this, and so does my bank in the login page. May be some text, a doodle or picture. Curiously, Wikipedia only seems to know about physical seals. Searching for "security seal login" yields some info.
    - tlrobinson 15y ago
      RSA's implementation (used by BofA, among others) is called SiteKey: http://en.wikipedia.org/wiki/SiteKey http://en.wikipedia.org/wiki/SiteKey These never seemed very secure to me for the reason mentioned in that article: The obvious flaw in the design is that a phishing site can get the correct SiteKey info from the genuine site, then serve it to the user, "proving" its legitimacy[1]. SiteKey is thus susceptible to a man-in-the-middle attack. But at least it requires the attacker to connect to the website, which gives them opportunity to block hosts that are known or suspected to be phishing users.
      - boucher 15y ago
        And of course that vulnerability would not exist here, in that the information would not web accessible, but rather only accessible to the local operating system.
ashbrahma 15y ago
"I can’t think of any reason why Twitter would force native apps through OAuth other than to create a hurdle that steers users toward Twitter’s own official native clients" > I think this nails it.
drivebyacct2 15y ago
I'm not giving my username and password to my online accounts to random native or web apps when the service in online account in question provides oAuth.
- bonaldi 15y ago
  and you can verify the embedded-in-a-web-view-with-no-url-bar login page how, exactly?
  - jrockway 15y ago
    By not using iOS. Other mobile operating systems can run more than one application at once, allowing the OAuth sequence to open in a browser you control.
    - bonaldi 15y ago
      iOS can do this too. But most developers use in-app web views to try and make it slightly nicer for their users. It's too late to demand that oAuth always go to the native browser. You use oAuth apps, chances are you're using an embedded view that you're taking on trust.
  - jmillikin 15y ago
    My browser is already signed in to twitter/identica/whatever page is being requested. If the login page appears at all, it means the app is doing something shady.
    - ceejayoz 15y ago
      Twitter always presents a login page, even if you're already logged in.
Rickasaurus 15y ago
Cry me a river of data mined tears.
terhechte 15y ago
It's clear that Twitter wants to move innovation in their ecosystem away from native clients that duplicate their exiting functionality. Instead they seem to be keen to support projects that offer innovative ways of displaying, sorting, or working with Twitter's firehose. Instagram does something similar. Their API terms of use read: "You cannot replicate the core user experience of Instagram.com" (http://instagram.com/developer/ http://instagram.com/developer/) I guess it is a matter of keeping potential future monetization options.
- LokiSnake 15y ago
  So pretty much a shit sandwich from Twitter. The thing is Twitter probably would not have been nearly as successful without all the 3rd party mobile apps, and now Twitter is screwing with the people that contributed to Twitter's own success.
  - ceejayoz 15y ago
    Essentially, Twitter's API is starting to look like it was secretly an on spec contest to build their official client.
    - LokiSnake 15y ago
      I wouldn't even call it that. They bought out Tweetie and made that their official client, then proceed to make it a pain in the ass for all other Twitter apps.
tolmasky 15y ago
Not sure if this would break some TOS or something but can't a native app just continue asking you for your username and password and just do this oath stuff in an offscreen webview, making it seem just like with xauth? It's almost disingenuous to show an in app browser with oath and confuse the user into thinking he has the same sort of "same origin" security as oath in the browser -- he doesn't, that webview is completely controlled by the app and thus offers no additional security over xauth whatsoever.
- mattmanser 15y ago
  From a technical perspective, what you're talking about is something that would be very brittle and liable to break because of changes Twitter make to their login pages. It's also relying on functionality that may be treated in the future as an attack vector and locked down by either Apple or Twitter. e.g. like the changes a lot of web browsers made to cross-domain ajax posts, pop-ups, pop-unders, etc.
  - tolmasky 15y ago
    Everything you are describing being "locked down" happened within the context of the browser world, not to webviews you control. Again, once you are in control of the webview you can do anything. Think of this way: you could just implement your own HTML renderer, at which point, once again, nothing anyone builds in will matter. In fact, why bother embedding a webview at all? Depending on how they implemented the login, simply download the HTML source code as plaintext, then issue the post of the form yourself -- no browser required. Each of these is slightly more abstracted, but you get the idea. I agree with your point that this may be brittle, but that's kind of the point I'm making -- you're getting zero new security benefits out of it and introducing the possibility that many apps use a worse technique to get what they want done. Also, if you are just manually filling out a form I wouldn't worry about brittleness too much, you're just looking for two text fields and then submitting whatever form contains them yourself. Unless Twitter actively starts trying to create fake form elements or something I doubt anything would break, and even then, is this really what Twitter wants to get in the business of building, tricky forms to swat third party apps?
- 15y ago
jrockway 15y ago
I'm OK with requiring OAuth. It's hard to trust third parties with data they collect themselves: see Sony and Gawker. It's even harder to trust them with data that belongs to someone else: they might one-way-hash their own passwords, of course, but they can't do that to your Twitter password. It's probably sitting in a database, cleartext, for every rogue employee or cracker to see. Even if you don't care about someone having your credentials, you can't trust them not to intentionally or accidentally misuse your account. The only way to trust a third party is to give them an account that can only perform the actions that you specify, and that's exactly what OAuth does. Of course you have to use Twitter's site for that: that's where the trust comes from. Anyway, I've used Android apps that pop open a web browser for the authentication part and then return you to the native app. It's, by definition, not seamless... but it's not confusing or slow or difficult or annoying. I imagine the experience is similar on iOS and Blackberry. So I don't see a problem here: all I see is the ability for users to have better protection over their personal information. That means they will be more willing to try your product, because the damage it can cause is limited. Less risk, more opportunity for innovation. Hardly a "shit sandwich".
- yeag123 15y ago
  My understanding is that inorder for a developer to receive an xAuth application key, they have to first be vetted by a representative from twitter. This involves exchanging information regarding a summary of the app, how it will be using the API, etc. So there is still some existing measure of security regarding xAuth, although not nearly as much oauth.
- jpk 15y ago
  I agree, this is a little dramatic. Another thing I'd point out is that the author is putting way too much emphasis on the login part of the experience. Is OAuth seamless? Clearly not. But it works, and it's a one-time thing. If you want to improve the user's experience, and you're harping on OAuth, you're implying that everything else the user touches is perfect. Amdahl would be disappointed.
  - protomyth 15y ago
guan 15y ago
Twitter has shown quite a lack of taste in recent months (e.g. dickbar). I wouldn’t be surprised if they simply hadn’t thought about these issues, and that it’s not a sinister plan to further encourage use of the official Twitter apps.
- JCB_K 15y ago
  Seriously...they're not stupid.
sriramk 15y ago
The common OAuth flow inside a mobile app is to show a web browser dialog which loads Webkit/IE/etc and show you the Twitter log-in UI. Frankly, I have no idea how to verify this page is actually Twitter's UI - there is no browser chrome, no SSL lock icon or any other trust indicators. It could as easily be just a random dialog constructed by the app author. I just don't see the value-add of OAuth in mobile app scenarios. Note that xAuth doesn't mean the app stores the passwords - you store a token like in OAuth. Of course, whether the app developer can be trusted to not store the username/password is a different story. Btw, I have a popular WP7 app which uses xauth, primarily because Twitter's login screen is broken on the Windows Phone browser.
- emullet 15y ago
  Facebook's OAuth flow has the same issue re verifying that its an actual Facebook login. I think browser chrome would go a ways to help me feel its a legit login.
  - brianpan 15y ago
    > help me feel its a legit login Inside a native app, that's all it would be. A feel good, since I could create the browsery chrome to look however I wanted (e.g. a URL bar that shows twitter.com when the page is mycredsharvest.com).
    - tesseract 15y ago
      Or for that matter, display the actual twitter.com page and keylog the credentials. It's a native app, after all.
    - bruceboughton 15y ago
      In theory, Apple could develop some unique chrome for this and then reject any app from the app store that fakes it. That is probably the only way to do this securely with good UX in a mobile app. It's not clear that Apple wants to take on that role though.
  - georgemcbay 15y ago
BlazingFrog 15y ago
> "So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth" Yes there is. I don't trust the developer enough to give her/him my user ID and password so OAuth works for me.
- gridspy 15y ago
  You can't trust that the webview (controlled by the app) isn't intercepting your credentials.
- tolmasky 15y ago
  The point is that this is an illusion. If the native app puts up an in app browser (which is a very common strategy), then they have access to everything you type. They can query the page for that same username and password, they can simulate clicks, they can do whatever they want. And additionally, for all you know, its not even the real page you are seeing. OAuth security only makes sense on the web.
  - zmmmmm 15y ago
    Well, there are different layers of trust. I trust the intent of many app developers, I just don't trust their competence to store my credentials securely. So OAuth still requires me to trust their intent, but does solve the problem of competence (as long as I trust them to implement OAuth properly which can also be an issue).
    - mnutt 15y ago
      And that's exactly what xAuth is. It just drops the pretense that oAuth inside a developer-controlled webview is trusted, authenticates directly using email/password, and then stores a token like oAuth.
      - zmmmmm 15y ago
        When implemented using a contained web view I agree, it's not terribly useful and arguably even harmful. However if the user is directed through the real browser then they can clearly see where they are logging in and doing the authorisation. This is partly just a problem with iOS and it's limited ability to flow and pass data between apps than OAuth per se.
grandalf 15y ago
If Twitter were simply to implement Oauth2 this would not be an issue.
- DenisM 15y ago
  How so? Oauth2 still requires a web-browser part to it.
  - leon_ 15y ago
    OAuth 2 is way less cumbersome than OAuth 1.0a. Switching from username/pass to OAuth 2 would have been far less a PITA than switching to 1.0a where you have to encrypt/sign the requests by hand. http://stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1 http://stackoverflow.com/questions/4113934/how-is-oauth-2-di... <- this is a pretty nice summary
ak1394 15y ago
Wow. I guess I'll be shutting down my feature-phone twitter client because of it. It's been in life-support mode for about a year, but I guess that's the end of it.
- mtogo 15y ago
  If /this/ ends your app, it was dead a long time ago.
  - ceejayoz 15y ago
    Decisions like this are making it clear that Twitter no longer cares about third-party clients. That they didn't even consider (that, or they just didn't care) that two weeks notice wouldn't be enough for many devs to make the change and get it through App Store approval is quite telling. It's not the technical difficulty of implementing that's a barrier. It's the clear "fuck off" signals Twitter has been sending.
daveman692 15y ago
This would become quite a bit simpler if they also moved to OAuth 2.0 (bearer tokens over SSL) instead of sticking with 1.1 (HMAC signatures).
- gavinballard 15y ago
  The type of token isn't what at's issue here, it's the method of obtaining one. OAuth 2.0 doesn't make a distinction between bearer and HMAC tokens during the authori[s]ation phase, which is what this article and discussion is about. By the by, bearer tokens over SSL are not a great option given the lax enforcement of SSL policy by many actors in the domain. HMAC tokens provide a much higher level of security (and, contrary to your implication, are specified alongside bearer tokens with the OAuth 2.0 specification).
zyb09 15y ago
Yes! I'm glad finally someone like Gruber shared his opinion on this. Integrating Twitter in native apps has been a huge pain for me and trying to explain clients why they can't have a native branded user/password dialog in the app (like "all" the other apps) is really tedious. For such a big player like Twitter they made it really cumbersome for 3rd partys to do simple tasks like posting a tweet.
deleted 15y ago
[deleted]
kqueue 15y ago
twitter xAuth is not secure. Why do you want me to hand over my username/password to a third party service?
tomkarlo 15y ago
What if Twitter decides to start putting ads for its own native clients on the OAuth screen? Given recent history, is there any reason this would be a surprise?
neovive 15y ago
On a related note. Did anyone else notice today's removal of the "status" query string variable and the switch solely to "Web Intents"? http://dev.twitter.com/pages/intents http://dev.twitter.com/pages/intents. I believe many Twitter sharing buttons used the simpler query string approach over the full API with OAuth.
- ramen 15y ago
  Not until you mentioned it. Thanks for pointing this out.
joe_the_user 15y ago
Hey, I'm designing a Twitter desktop client from the ground-up with Oauth. It is annoyingly over-complexified but doable. I suppose I can take a grim pleasure that others will have to suffer with me...
- chc 15y ago
  Given that it looks like Twitter might not even allow new clients access, I reckon you're in for a bit more grim pleasure.
philfreo 15y ago
The flow of OAuth on mobile is not nearly as bad when the app opens Safari to the OAuth screen, and when the user hits accept/reject they get sent to a URI like myappname://oauth which the iPhone app can register to mean relaunch the app
- 2mur 15y ago
  You can do the same thing in Android too. You have an application specific uri that you register in your manifest.
ashbrahma 15y ago
Ryan Sarver (@rsarver) has posted a response with updates based on feedback: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/e954fc0f8b5aa6ec/dbe591c0088a4b18 http://groups.google.com/group/twitter-development-talk/brow...
gcampbell 15y ago
The deadline has been pushed back two weeks to June 14: http://groups.google.com/group/twitter-development-talk/msg/dbe591c0088a4b18 http://groups.google.com/group/twitter-development-talk/msg/...
nhangen 15y ago
Isn't Facebook doing the same thing? In fact, I just got an email from them today that they're forcing the issue and all devs must adopt oAuth by September.
evgen 15y ago
At what point is someone going to just say "fuck Twitter, Inc." and create a library of simple web-scrapers that emulates most of the API that twitter has been trying to claw back from the third-party dev community for the past year via the standard http interface? Such a library may be brittle, but it can't be much worse than the "yeah, we told you to do this a couple of months ago but now we changed our minds and you have two weeks to comply with our new policy" status that exists now?
buddydvd 15y ago
Browser-based OAuth flow (like Facebook's new iOS SDK -- the one that avoids using embedded webview) has two advantages: 1.) Single sign on. If you're already logged in to the site in the browser, you don't have to enter your user/password again. Also, if you don't trust the app invoking the web browser, you can always exit the app and pre-login to site with the web browser before running the app again. 2.) Optional interstitial pages. Sometimes, your account may be accessed from some questionable location. The OAuth flow enables challenging users with additional security questions before giving authorization to the app (e.g. Facebook's identify-your-friends'-faces challenge, enter-your-birthday challenge, etc.)
leon_ 15y ago
The last time I looked xAuth was not available for everyone. You had to request access to it and they often wouldn't give you the access. I didn't get xAuth for my apps so I had to go the OAuth way. And I believe only a few popular apps got xAuth.
beerglass 15y ago
The biggest issue with Twitter oAuth sign-in that we have faced as developers is that the Twitter sign-in page does not work at all or is not optimized for feature phones with smaller screens and not running Webkit based browser. Always wished that Twitter provided a URL - twitter.com/appname that users could go to and assign all permissions and got a simple key + PIN that they could enter in our app to access their tweets.
chopsueyar 15y ago
Your CSS fonts are tiny.

219 points by berberich 15y ago

As many others have pointed out, OAuth is extremely susceptible to phishing or snooping of passwords on platforms where the OAuth flow is done in an embedded web view, which can be considered "untrusted", vs. your browser which could be considered "trusted" because you know the URL bar is accurate, and there's no mechanism for 3rd parties to scrape passwords (well, except for user scripts / extensions) OAuth does also remove the burden of securely storing passwords, but so does xAuth.

boucher 15y ago
Of course, OAuth is also vulnerable to phishing in a "trusted" browser, when you're talking about average users who don't really understand how it works. One interesting way to provide "trust" would be to have a system wide "OAuth" view (or, "secure browser," or whatever you want to call it). It would have to contain some piece of user information, like say your user account name and photo, that the app itself is never granted access to. That way, if you're actually paying attention you can verify that the system displayed this view.
- ableal 15y ago
  It would have to contain some piece of user information, like say your user account name and photo, that the app itself is never granted access to. A security seal, defined by the user (one time operation). Yahoo used to have this, and so does my bank in the login page. May be some text, a doodle or picture. Curiously, Wikipedia only seems to know about physical seals. Searching for "security seal login" yields some info.
  - tlrobinson 15y ago
    RSA's implementation (used by BofA, among others) is called SiteKey: http://en.wikipedia.org/wiki/SiteKey http://en.wikipedia.org/wiki/SiteKey These never seemed very secure to me for the reason mentioned in that article: The obvious flaw in the design is that a phishing site can get the correct SiteKey info from the genuine site, then serve it to the user, "proving" its legitimacy[1]. SiteKey is thus susceptible to a man-in-the-middle attack. But at least it requires the attacker to connect to the website, which gives them opportunity to block hosts that are known or suspected to be phishing users.
    - boucher 15y ago
      And of course that vulnerability would not exist here, in that the information would not web accessible, but rather only accessible to the local operating system.

ashbrahma 15y ago

"I can’t think of any reason why Twitter would force native apps through OAuth other than to create a hurdle that steers users toward Twitter’s own official native clients" > I think this nails it.

drivebyacct2 15y ago

I'm not giving my username and password to my online accounts to random native or web apps when the service in online account in question provides oAuth.

bonaldi 15y ago
and you can verify the embedded-in-a-web-view-with-no-url-bar login page how, exactly?
- jrockway 15y ago
  By not using iOS. Other mobile operating systems can run more than one application at once, allowing the OAuth sequence to open in a browser you control.
  - bonaldi 15y ago
    iOS can do this too. But most developers use in-app web views to try and make it slightly nicer for their users. It's too late to demand that oAuth always go to the native browser. You use oAuth apps, chances are you're using an embedded view that you're taking on trust.
- jmillikin 15y ago
  My browser is already signed in to twitter/identica/whatever page is being requested. If the login page appears at all, it means the app is doing something shady.
  - ceejayoz 15y ago
    Twitter always presents a login page, even if you're already logged in.

Rickasaurus 15y ago

Cry me a river of data mined tears.

terhechte 15y ago

It's clear that Twitter wants to move innovation in their ecosystem away from native clients that duplicate their exiting functionality. Instead they seem to be keen to support projects that offer innovative ways of displaying, sorting, or working with Twitter's firehose. Instagram does something similar. Their API terms of use read: "You cannot replicate the core user experience of Instagram.com" (http://instagram.com/developer/ http://instagram.com/developer/) I guess it is a matter of keeping potential future monetization options.

LokiSnake 15y ago
So pretty much a shit sandwich from Twitter. The thing is Twitter probably would not have been nearly as successful without all the 3rd party mobile apps, and now Twitter is screwing with the people that contributed to Twitter's own success.
- ceejayoz 15y ago
  Essentially, Twitter's API is starting to look like it was secretly an on spec contest to build their official client.
  - LokiSnake 15y ago
    I wouldn't even call it that. They bought out Tweetie and made that their official client, then proceed to make it a pain in the ass for all other Twitter apps.

tolmasky 15y ago

Not sure if this would break some TOS or something but can't a native app just continue asking you for your username and password and just do this oath stuff in an offscreen webview, making it seem just like with xauth? It's almost disingenuous to show an in app browser with oath and confuse the user into thinking he has the same sort of "same origin" security as oath in the browser -- he doesn't, that webview is completely controlled by the app and thus offers no additional security over xauth whatsoever.

mattmanser 15y ago
From a technical perspective, what you're talking about is something that would be very brittle and liable to break because of changes Twitter make to their login pages. It's also relying on functionality that may be treated in the future as an attack vector and locked down by either Apple or Twitter. e.g. like the changes a lot of web browsers made to cross-domain ajax posts, pop-ups, pop-unders, etc.
- tolmasky 15y ago
  Everything you are describing being "locked down" happened within the context of the browser world, not to webviews you control. Again, once you are in control of the webview you can do anything. Think of this way: you could just implement your own HTML renderer, at which point, once again, nothing anyone builds in will matter. In fact, why bother embedding a webview at all? Depending on how they implemented the login, simply download the HTML source code as plaintext, then issue the post of the form yourself -- no browser required. Each of these is slightly more abstracted, but you get the idea. I agree with your point that this may be brittle, but that's kind of the point I'm making -- you're getting zero new security benefits out of it and introducing the possibility that many apps use a worse technique to get what they want done. Also, if you are just manually filling out a form I wouldn't worry about brittleness too much, you're just looking for two text fields and then submitting whatever form contains them yourself. Unless Twitter actively starts trying to create fake form elements or something I doubt anything would break, and even then, is this really what Twitter wants to get in the business of building, tricky forms to swat third party apps?
15y ago

jrockway 15y ago

I'm OK with requiring OAuth. It's hard to trust third parties with data they collect themselves: see Sony and Gawker. It's even harder to trust them with data that belongs to someone else: they might one-way-hash their own passwords, of course, but they can't do that to your Twitter password. It's probably sitting in a database, cleartext, for every rogue employee or cracker to see. Even if you don't care about someone having your credentials, you can't trust them not to intentionally or accidentally misuse your account. The only way to trust a third party is to give them an account that can only perform the actions that you specify, and that's exactly what OAuth does. Of course you have to use Twitter's site for that: that's where the trust comes from. Anyway, I've used Android apps that pop open a web browser for the authentication part and then return you to the native app. It's, by definition, not seamless... but it's not confusing or slow or difficult or annoying. I imagine the experience is similar on iOS and Blackberry. So I don't see a problem here: all I see is the ability for users to have better protection over their personal information. That means they will be more willing to try your product, because the damage it can cause is limited. Less risk, more opportunity for innovation. Hardly a "shit sandwich".

yeag123 15y ago
My understanding is that inorder for a developer to receive an xAuth application key, they have to first be vetted by a representative from twitter. This involves exchanging information regarding a summary of the app, how it will be using the API, etc. So there is still some existing measure of security regarding xAuth, although not nearly as much oauth.
jpk 15y ago
I agree, this is a little dramatic. Another thing I'd point out is that the author is putting way too much emphasis on the login part of the experience. Is OAuth seamless? Clearly not. But it works, and it's a one-time thing. If you want to improve the user's experience, and you're harping on OAuth, you're implying that everything else the user touches is perfect. Amdahl would be disappointed.
- protomyth 15y ago

guan 15y ago

Twitter has shown quite a lack of taste in recent months (e.g. dickbar). I wouldn’t be surprised if they simply hadn’t thought about these issues, and that it’s not a sinister plan to further encourage use of the official Twitter apps.

JCB_K 15y ago
Seriously...they're not stupid.

sriramk 15y ago

The common OAuth flow inside a mobile app is to show a web browser dialog which loads Webkit/IE/etc and show you the Twitter log-in UI. Frankly, I have no idea how to verify this page is actually Twitter's UI - there is no browser chrome, no SSL lock icon or any other trust indicators. It could as easily be just a random dialog constructed by the app author. I just don't see the value-add of OAuth in mobile app scenarios. Note that xAuth doesn't mean the app stores the passwords - you store a token like in OAuth. Of course, whether the app developer can be trusted to not store the username/password is a different story. Btw, I have a popular WP7 app which uses xauth, primarily because Twitter's login screen is broken on the Windows Phone browser.

emullet 15y ago
Facebook's OAuth flow has the same issue re verifying that its an actual Facebook login. I think browser chrome would go a ways to help me feel its a legit login.
- brianpan 15y ago
  > help me feel its a legit login Inside a native app, that's all it would be. A feel good, since I could create the browsery chrome to look however I wanted (e.g. a URL bar that shows twitter.com when the page is mycredsharvest.com).
  - tesseract 15y ago
    Or for that matter, display the actual twitter.com page and keylog the credentials. It's a native app, after all.
  - bruceboughton 15y ago
    In theory, Apple could develop some unique chrome for this and then reject any app from the app store that fakes it. That is probably the only way to do this securely with good UX in a mobile app. It's not clear that Apple wants to take on that role though.
- georgemcbay 15y ago

BlazingFrog 15y ago

> "So long as you remain within the app, there’s no security advantage for OAuth in an embedded web view over xAuth" Yes there is. I don't trust the developer enough to give her/him my user ID and password so OAuth works for me.

gridspy 15y ago
You can't trust that the webview (controlled by the app) isn't intercepting your credentials.
tolmasky 15y ago
The point is that this is an illusion. If the native app puts up an in app browser (which is a very common strategy), then they have access to everything you type. They can query the page for that same username and password, they can simulate clicks, they can do whatever they want. And additionally, for all you know, its not even the real page you are seeing. OAuth security only makes sense on the web.
- zmmmmm 15y ago
  Well, there are different layers of trust. I trust the intent of many app developers, I just don't trust their competence to store my credentials securely. So OAuth still requires me to trust their intent, but does solve the problem of competence (as long as I trust them to implement OAuth properly which can also be an issue).
  - mnutt 15y ago
    And that's exactly what xAuth is. It just drops the pretense that oAuth inside a developer-controlled webview is trusted, authenticates directly using email/password, and then stores a token like oAuth.
    - zmmmmm 15y ago
      When implemented using a contained web view I agree, it's not terribly useful and arguably even harmful. However if the user is directed through the real browser then they can clearly see where they are logging in and doing the authorisation. This is partly just a problem with iOS and it's limited ability to flow and pass data between apps than OAuth per se.

grandalf 15y ago

If Twitter were simply to implement Oauth2 this would not be an issue.

DenisM 15y ago
How so? Oauth2 still requires a web-browser part to it.
- leon_ 15y ago
  OAuth 2 is way less cumbersome than OAuth 1.0a. Switching from username/pass to OAuth 2 would have been far less a PITA than switching to 1.0a where you have to encrypt/sign the requests by hand. http://stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1 http://stackoverflow.com/questions/4113934/how-is-oauth-2-di... <- this is a pretty nice summary

ak1394 15y ago

Wow. I guess I'll be shutting down my feature-phone twitter client because of it. It's been in life-support mode for about a year, but I guess that's the end of it.

mtogo 15y ago
If /this/ ends your app, it was dead a long time ago.
- ceejayoz 15y ago
  Decisions like this are making it clear that Twitter no longer cares about third-party clients. That they didn't even consider (that, or they just didn't care) that two weeks notice wouldn't be enough for many devs to make the change and get it through App Store approval is quite telling. It's not the technical difficulty of implementing that's a barrier. It's the clear "fuck off" signals Twitter has been sending.

daveman692 15y ago

This would become quite a bit simpler if they also moved to OAuth 2.0 (bearer tokens over SSL) instead of sticking with 1.1 (HMAC signatures).

gavinballard 15y ago
The type of token isn't what at's issue here, it's the method of obtaining one. OAuth 2.0 doesn't make a distinction between bearer and HMAC tokens during the authori[s]ation phase, which is what this article and discussion is about. By the by, bearer tokens over SSL are not a great option given the lax enforcement of SSL policy by many actors in the domain. HMAC tokens provide a much higher level of security (and, contrary to your implication, are specified alongside bearer tokens with the OAuth 2.0 specification).

zyb09 15y ago

Yes! I'm glad finally someone like Gruber shared his opinion on this. Integrating Twitter in native apps has been a huge pain for me and trying to explain clients why they can't have a native branded user/password dialog in the app (like "all" the other apps) is really tedious. For such a big player like Twitter they made it really cumbersome for 3rd partys to do simple tasks like posting a tweet.

deleted 15y ago

[deleted]

kqueue 15y ago

twitter xAuth is not secure. Why do you want me to hand over my username/password to a third party service?

tomkarlo 15y ago

What if Twitter decides to start putting ads for its own native clients on the OAuth screen? Given recent history, is there any reason this would be a surprise?

neovive 15y ago

On a related note. Did anyone else notice today's removal of the "status" query string variable and the switch solely to "Web Intents"? http://dev.twitter.com/pages/intents http://dev.twitter.com/pages/intents. I believe many Twitter sharing buttons used the simpler query string approach over the full API with OAuth.

ramen 15y ago
Not until you mentioned it. Thanks for pointing this out.

joe_the_user 15y ago

Hey, I'm designing a Twitter desktop client from the ground-up with Oauth. It is annoyingly over-complexified but doable. I suppose I can take a grim pleasure that others will have to suffer with me...

chc 15y ago
Given that it looks like Twitter might not even allow new clients access, I reckon you're in for a bit more grim pleasure.

philfreo 15y ago

The flow of OAuth on mobile is not nearly as bad when the app opens Safari to the OAuth screen, and when the user hits accept/reject they get sent to a URI like myappname://oauth which the iPhone app can register to mean relaunch the app

2mur 15y ago
You can do the same thing in Android too. You have an application specific uri that you register in your manifest.

ashbrahma 15y ago

Ryan Sarver (@rsarver) has posted a response with updates based on feedback: http://groups.google.com/group/twitter-development-talk/browse_thread/thread/e954fc0f8b5aa6ec/dbe591c0088a4b18 http://groups.google.com/group/twitter-development-talk/brow...

gcampbell 15y ago

The deadline has been pushed back two weeks to June 14: http://groups.google.com/group/twitter-development-talk/msg/dbe591c0088a4b18 http://groups.google.com/group/twitter-development-talk/msg/...

nhangen 15y ago

Isn't Facebook doing the same thing? In fact, I just got an email from them today that they're forcing the issue and all devs must adopt oAuth by September.

evgen 15y ago

At what point is someone going to just say "fuck Twitter, Inc." and create a library of simple web-scrapers that emulates most of the API that twitter has been trying to claw back from the third-party dev community for the past year via the standard http interface? Such a library may be brittle, but it can't be much worse than the "yeah, we told you to do this a couple of months ago but now we changed our minds and you have two weeks to comply with our new policy" status that exists now?

buddydvd 15y ago

Browser-based OAuth flow (like Facebook's new iOS SDK -- the one that avoids using embedded webview) has two advantages: 1.) Single sign on. If you're already logged in to the site in the browser, you don't have to enter your user/password again. Also, if you don't trust the app invoking the web browser, you can always exit the app and pre-login to site with the web browser before running the app again. 2.) Optional interstitial pages. Sometimes, your account may be accessed from some questionable location. The OAuth flow enables challenging users with additional security questions before giving authorization to the app (e.g. Facebook's identify-your-friends'-faces challenge, enter-your-birthday challenge, etc.)

leon_ 15y ago

The last time I looked xAuth was not available for everyone. You had to request access to it and they often wouldn't give you the access. I didn't get xAuth for my apps so I had to go the OAuth way. And I believe only a few popular apps got xAuth.

beerglass 15y ago

The biggest issue with Twitter oAuth sign-in that we have faced as developers is that the Twitter sign-in page does not work at all or is not optimized for feature phones with smaller screens and not running Webkit based browser. Always wished that Twitter provided a URL - twitter.com/appname that users could go to and assign all permissions and got a simple key + PIN that they could enter in our app to access their tweets.

chopsueyar 15y ago

Your CSS fonts are tiny.