[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone
Pictures in email signatures is obnoxious and annoying. Zac Bowling On Tue, Aug 11, 2009 at 2:58 PM, Bradley S. O'Hearne wrote: > Alex, > Thank you for the information -- that does give me a much better idea of the > helpful utility of OAuth within the Twitter ecosystem. Please understand, my > point in raising these issues has never been to buck the system, but rather > to prove out what the real security issues in play are, so as to address > them as efficiently as possible. Stickiness is a major issue in mobile apps, > and every hoop you put the user through increases the chances for a user to > leave and / or delete your app. > As for the iPhone-optimized version of the OAuth workflow -- I run a company > specializing in iPhone development. If Twitter would be in need of our > services to can OAuth into a distributable component / library or set of > source code, somewhat in the vein of Facebook Connect, contact me offline. > Regards, > Brad > Brad O'Hearne > Owner / Developer > Big Hill Software > br...@bighillsoftware.com > http://www.bighillsoftware.com > > On Aug 11, 2009, at 10:40 AM, Alex Payne wrote: > > For the case of a dedicated application on a rich mobile platform like > iPhone, I agree that OAuth does not offer a particularly different user > experience. It does, however, provide us at Twitter the information we need > to provide detailed usage analytics back to developers, as well as the data > we need to better understand our platform and help it grow. > OAuth also provides a mechanism for users to revoke access to applications > that aren't behaving as they expected; on the iPhone, removing a misbehaving > application is as simple as deleting it, but for some non-technical users it > may be helpful for them to visit their Twitter settings and see the list of > applications they've authorized. > We're working with our mobile team on improving the iPhone-optimized version > of the OAuth workflow. It may not be an enormous improvement over > password-based authentication, but once it's done, it certainly won't be a > hinderance. Twitter is one of many companies moving to OAuth, and you can > already find iPhone applications like TripIt that rely solely on OAuth for > authentication. > > On Mon, Aug 10, 2009 at 14:16, Bradley S. O'Hearne > wrote: >> >> All, >> >> I don't want to kick this subject to death, as there was a lengthy thread >> on general OAuth vs. Basic auth -- I want to restrict this question strictly >> to the scope of iPhone apps. Having pored over the OAuth vs. Basic >> authentication process, I have a question, given the following assumptions: >> >> - The iPhone app is communicating directly with Twitter, i.e. not through >> some third-party means. >> >> - The iPhone app requires authentication at the beginning of each >> application runtime (i.e. each time the app is run the user has to type in >> their password). >> >> - The password is cached only in memory, for the life of that specific >> runtime (i.e. when the user quits the app, the password is released). >> >> - The password is NEVER persisted anywhere, i.e. never stored to disk. >> >> - All network communication with Twitter takes place over HTTPS. >> >> If all of those things are true in an iPhone app, how is OAuth superior in >> any way to basic authentication from a security standpoint? Furthermore, >> given having to introduce a foreign UI element and extra authentication >> steps over the web, could OAuth even be considered inferior when evaluated >> as a whole as an authentication means for the iPhone, when app branding, >> integration, and ease of use are considered? >> >> Mind you, the purpose of this post is not in any way to incite a religious >> war or stir the pot, it is to definitively establish the true pros and cons >> of each authentication means within the specific use case of the iPhone >> only. Many of the other OAuth / Basic auth threads are somewhat overridden >> with personally charged statements that I'd rather ignore them. >> >> Anyway, your constructive views are most appreciated. >> >> Regards, >> >> Brad >> >> > > > > -- > Alex Payne - Platform Lead, Twitter, Inc. > http://twitter.com/al3x > >
[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone
> I am not aware of UIWebView and have no idea of what it does. It is, essentially, a browser object. -- personal: http://www.cameronkaiser.com/ -- Cameron Kaiser * Floodgap Systems * www.floodgap.com * ckai...@floodgap.com -- I can't complain, but sometimes I still do. -- Joe Walsh ---
[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone
> > << if you choose to run a rogue executable on your computer, it isn't the > computer's fault for running it. It is the user's fault for running the > executable. >> > Exactly. It is the users fault. If all third party apps are forced to implement OAuth it would save users from this fault to some extent. > < > No? How is it then that you initially get logged into Twitter -- yes, it > might be a Twitter web page, but it is still hosted within your app, right? > So whose to say the web page you are viewing is *really* an OAuth page, if > you aren't going to trust the app? OAuth doesn't protect from that. >> > I was actually referring to Desktop PIN based apps(the desktop typically invokes a browser and control is passed to browser . Yes there is a hit on user experience ). I am not aware of UIWebView and have no idea of what it does. But if the credentials are passed through consumer then it is CERTAINLY NOT OAuth. It is as bad as using BASIC Auth. > > > < at all. If basic authentication is used, and passwords are never stored, it > doesn't matter if someone steals your iPhone, they cannot get access to your > Twitter account. *With OAuth, they would still have a degree of access to > it, unless I'm missing something*.>> > Not necessarily. Its up to the application. Applications typically provide an option of storing/clearing passwords/tokens. You cannot assume that only Oauth apps always store tokens.All apps store password/tokens as they do not want the users to go through the login process again. If your iphone gets stolen and if your oauth based app stores the token yes there is a degree of access to twitter but atleast you have the option of revoking the access.But it is not the same case with BASIC auth (and what if you are using same password for all your mail/shopping/bank accounts?) Srikanth > >
[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone
Why would it be hosted in your app? Why can't you open Safari? Obviously Safari is *more* trusted. But if you've already installed an untrusted app onto your machine, the untrusted app has enough power to keylog, brute force your keychain (or other password db), send personal info over the net, or any number of other horrible things. Going through a browser fixes many things, but not all of them. And it does come with one huge limitation -- that it makes your user have to jump through yet another hoop to authenticate for what seems (to me, at least) to be "security theater." Each hoop always increases your support load and/or limits your customer base -- both costly. I try to avoid costly things with questionable advantages. ;-) The de facto mechanism for dealing with this on the iPhone is to use an integrated WebView. It *is* Safari for all intents and purposes, but it prevents the user from getting booted out to another app and having to find their way back to your app, launch it, and then enter the correct info in the correct spot. It's a huge win for the Ux. And using this same approach on the desktop isn't a half-bad idea either. In case it wasn't already mentioned in this thread there are a couple open source projects that implement oAuth solutions that behave in exactly this way: For iPhone: http://github.com/bengottlieb/Twitter-OAuth-iPhone/ For Mac OS X: http://github.com/yourhead/OAuth_ObjC_Test_App/ Isaiah YourHead Software http://www.yourhead.com On Aug 11, 2009, at 12:58 PM, JDG wrote: Why would it be hosted in your app? Why can't you open Safari? On Tue, Aug 11, 2009 at 13:29, Bradley S. O'Hearne > wrote: Srikanth, By third party i meant some one like 'TwitViewer' (some one who would pay and register their app in appstore and trick the users to believe in them but who do not work the way they were expected to ) That's not a valid use case for faulting the authentication mechanism. The user has already demonstrated an explicit level of trust in the app. That's like saying that if you carelessly trusted someone with your ATM pin number prior to them performing a fraudulent transaction with your ATM card, that it is the ATM machine's fault. It isn't. The problem there is that you trusted a source you shouldn't have. Same thing with executable files containing viruses sent to you via email -- if you choose to run a rogue executable on your computer, it isn't the computer's fault for running it. It is the user's fault for running the executable. NO. With OAuth you are not keying in your password with in the app. No? How is it then that you initially get logged into Twitter -- yes, it might be a Twitter web page, but it is still hosted within your app, right? So whose to say the web page you are viewing is *really* an OAuth page, if you aren't going to trust the app? OAuth doesn't protect from that. Now assume your third party app is legitimate and supports basic auth and is storing password. If some one steals your iphone he could use your password (doesnt matter whether it is stored encrypted) as well as your app to post/delete tweets. With OAuth it is limited posting/deleting tweets. This is not to say that Oauth solves all the problems of storing passwords.(It has its own problems of storing consumer secrets) You ignored one of my assumptions, which is that passwords aren't stored at all. If basic authentication is used, and passwords are never stored, it doesn't matter if someone steals your iPhone, they cannot get access to your Twitter account. With OAuth, they would still have a degree of access to it, unless I'm missing something. Brad On Aug 11, 2009, at 10:33 AM, srikanth reddy wrote: By third party i meant some one like 'TwitViewer' (some one who would pay and register their app in appstore and trick the users to believe in them but who do not work the way they were expected to )> NO. With OAuth you are not keying in your password with in the app. > I have to agree with this particularly for desktop apps (But app store admins catch this.) > Now assume your third party app is legitimate and supports basic auth and is storing password. If some one steals your iphone he could use your password (doesnt matter whether it is stored encrypted) as well as your app to post/delete tweets. With OAuth it is limited posting/deleting tweets. This is not to say that Oauth solves all the problems of storing passwords.(It has its own problems of storing consumer secrets) If you are not storing pas
[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone
JDG, > Why would it be hosted in your app? Why can't you open Safari? The ideal usage pattern in an application is not to leave the application. Opening Safari requires exiting the current application. Opening a UIWebView within your application is the way to go. Brad On Aug 11, 2009, at 12:58 PM, JDG wrote: Why would it be hosted in your app? Why can't you open Safari? On Tue, Aug 11, 2009 at 13:29, Bradley S. O'Hearne > wrote: Srikanth, By third party i meant some one like 'TwitViewer' (some one who would pay and register their app in appstore and trick the users to believe in them but who do not work the way they were expected to ) That's not a valid use case for faulting the authentication mechanism. The user has already demonstrated an explicit level of trust in the app. That's like saying that if you carelessly trusted someone with your ATM pin number prior to them performing a fraudulent transaction with your ATM card, that it is the ATM machine's fault. It isn't. The problem there is that you trusted a source you shouldn't have. Same thing with executable files containing viruses sent to you via email -- if you choose to run a rogue executable on your computer, it isn't the computer's fault for running it. It is the user's fault for running the executable. NO. With OAuth you are not keying in your password with in the app. No? How is it then that you initially get logged into Twitter -- yes, it might be a Twitter web page, but it is still hosted within your app, right? So whose to say the web page you are viewing is *really* an OAuth page, if you aren't going to trust the app? OAuth doesn't protect from that. Now assume your third party app is legitimate and supports basic auth and is storing password. If some one steals your iphone he could use your password (doesnt matter whether it is stored encrypted) as well as your app to post/delete tweets. With OAuth it is limited posting/deleting tweets. This is not to say that Oauth solves all the problems of storing passwords.(It has its own problems of storing consumer secrets) You ignored one of my assumptions, which is that passwords aren't stored at all. If basic authentication is used, and passwords are never stored, it doesn't matter if someone steals your iPhone, they cannot get access to your Twitter account. With OAuth, they would still have a degree of access to it, unless I'm missing something. Brad On Aug 11, 2009, at 10:33 AM, srikanth reddy wrote: By third party i meant some one like 'TwitViewer' (some one who would pay and register their app in appstore and trick the users to believe in them but who do not work the way they were expected to )> NO. With OAuth you are not keying in your password with in the app. > I have to agree with this particularly for desktop apps (But app store admins catch this.) > Now assume your third party app is legitimate and supports basic auth and is storing password. If some one steals your iphone he could use your password (doesnt matter whether it is stored encrypted) as well as your app to post/delete tweets. With OAuth it is limited posting/deleting tweets. This is not to say that Oauth solves all the problems of storing passwords.(It has its own problems of storing consumer secrets) If you are not storing password then basic auth over https from a trusted app is absolutely fine. Personally i believe OAuth does not have much to offer for desktop apps.The debate goes on. Sooner or later twitter is going to remove basic auth support. We have no choice but to move on. On Tue, Aug 11, 2009 at 8:27 PM, Bradley S. O'Hearne > wrote: Srikanth, Thank you for your thoughts -- good ones. Responses: But what if the app was developed by some thirdparty devs? you never know whether the password is stored or logged some where. I'm not sure who the "third party" is relative to -- if you are the user of an iPhone app, *every* app was developed by a third party. If you are the developer of the app, and you are worried about development you've farmed out to a third party, well, that's not an authentication issue -- that's a personnel / business problem. You shouldn't be publishing code which you aren't aware of what it does. I made reference to this in another thread, but when a user voluntarily downloads an iPhone app and puts it on their device, and then runs it, they've explicitly demonstrated a level of trust for that app. If they are concerned about it being a rogue app, then downloading the app, putting it on their devi
[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone
Why would it be hosted in your app? Why can't you open Safari? On Tue, Aug 11, 2009 at 13:29, Bradley S. O'Hearne wrote: > Srikanth, > > By third party i meant some one like 'TwitViewer' (some one who would pay > and register their app in appstore and trick the users to believe in them > but who do not work the way they were expected to ) > > > That's not a valid use case for faulting the authentication mechanism. The > user has already demonstrated an explicit level of trust in the app. That's > like saying that if you carelessly trusted someone with your ATM pin number > prior to them performing a fraudulent transaction with your ATM card, that > it is the ATM machine's fault. It isn't. The problem there is that you > trusted a source you shouldn't have. Same thing with executable files > containing viruses sent to you via email -- if you choose to run a rogue > executable on your computer, it isn't the computer's fault for running it. > It is the user's fault for running the executable. > > NO. With OAuth you are not keying in your password with in the app. > > > No? How is it then that you initially get logged into Twitter -- yes, it > might be a Twitter web page, but it is still hosted within your app, right? > So whose to say the web page you are viewing is *really* an OAuth page, if > you aren't going to trust the app? OAuth doesn't protect from that. > > Now assume your third party app is legitimate and supports basic auth and > is storing password. If some one steals your iphone he could use your > password (doesnt matter whether it is stored encrypted) as well as your app > to post/delete tweets. With OAuth it is limited posting/deleting tweets. > This is not to say that Oauth solves all the problems of storing > passwords.(It has its own problems of storing consumer secrets) > > > You ignored one of my assumptions, which is that passwords aren't stored at > all. If basic authentication is used, and passwords are never stored, it > doesn't matter if someone steals your iPhone, they cannot get access to your > Twitter account. With OAuth, they would still have a degree of access to it, > unless I'm missing something. > > Brad > > > On Aug 11, 2009, at 10:33 AM, srikanth reddy wrote: > > By third party i meant some one like 'TwitViewer' (some one who would pay > and register their app in appstore and trick the users to believe in them > but who do not work the way they were expected to ) > > < developer of this so-called "rogue" app developed. >> > > NO. With OAuth you are not keying in your password with in the app. > > < password that way. >> > I have to agree with this particularly for desktop apps (But app store > admins catch this.) > > < password, not having the device as a whole password protected, and then > losing your device. Someone can then go into your phone, and Twitter related > app, and have direct access to your account (which I believe would still be > a danger with OAuth tokens).>> > > Now assume your third party app is legitimate and supports basic auth and > is storing password. If some one steals your iphone he could use your > password (doesnt matter whether it is stored encrypted) as well as your app > to post/delete tweets. With OAuth it is limited posting/deleting tweets. > This is not to say that Oauth solves all the problems of storing > passwords.(It has its own problems of storing consumer secrets) > > If you are not storing password then basic auth over https from a trusted > app is absolutely fine. > > Personally i believe OAuth does not have much to offer for desktop apps.The > debate goes on. > Sooner or later twitter is going to remove basic auth support. We have no > choice but to move on. > > On Tue, Aug 11, 2009 at 8:27 PM, Bradley S. O'Hearne < > brad.ohea...@gmail.com> wrote: > >> Srikanth, >> Thank you for your thoughts -- good ones. Responses: >> >> >> But what if the app was developed by some thirdparty devs? you never know >> whether the password is stored or logged some where. >> >> >> I'm not sure who the "third party" is relative to -- if you are the user >> of an iPhone app, *every* app was developed by a third party. If you are the >> developer of the app, and you are worried about development you've farmed >> out to a third party, well, that's not an authentication issue -- that's a >> personnel / business problem. You shouldn't be publishing code which you >> aren't aware of what it does. >> >> I made reference to this in another thread, but when a user voluntarily >> downloads an iPhone app and puts it on their device, and then runs it, >> they've explicitly demonstrated a level of trust for that app. If they are >> concerned about it being a rogue app, then downloading the app, putting it >> on their device, and running it seems inconsistent with a true concern about >> it being a rogue app. >> >> But furthermore, let's assume there was some concern about password entry >> -- I do not see how OAuth saves you at all. You are still keyi
[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone
Srikanth, By third party i meant some one like 'TwitViewer' (some one who would pay and register their app in appstore and trick the users to believe in them but who do not work the way they were expected to ) That's not a valid use case for faulting the authentication mechanism. The user has already demonstrated an explicit level of trust in the app. That's like saying that if you carelessly trusted someone with your ATM pin number prior to them performing a fraudulent transaction with your ATM card, that it is the ATM machine's fault. It isn't. The problem there is that you trusted a source you shouldn't have. Same thing with executable files containing viruses sent to you via email -- if you choose to run a rogue executable on your computer, it isn't the computer's fault for running it. It is the user's fault for running the executable. NO. With OAuth you are not keying in your password with in the app. No? How is it then that you initially get logged into Twitter -- yes, it might be a Twitter web page, but it is still hosted within your app, right? So whose to say the web page you are viewing is *really* an OAuth page, if you aren't going to trust the app? OAuth doesn't protect from that. Now assume your third party app is legitimate and supports basic auth and is storing password. If some one steals your iphone he could use your password (doesnt matter whether it is stored encrypted) as well as your app to post/delete tweets. With OAuth it is limited posting/deleting tweets. This is not to say that Oauth solves all the problems of storing passwords.(It has its own problems of storing consumer secrets) You ignored one of my assumptions, which is that passwords aren't stored at all. If basic authentication is used, and passwords are never stored, it doesn't matter if someone steals your iPhone, they cannot get access to your Twitter account. With OAuth, they would still have a degree of access to it, unless I'm missing something. Brad On Aug 11, 2009, at 10:33 AM, srikanth reddy wrote: By third party i meant some one like 'TwitViewer' (some one who would pay and register their app in appstore and trick the users to believe in them but who do not work the way they were expected to )> NO. With OAuth you are not keying in your password with in the app. > I have to agree with this particularly for desktop apps (But app store admins catch this.) > Now assume your third party app is legitimate and supports basic auth and is storing password. If some one steals your iphone he could use your password (doesnt matter whether it is stored encrypted) as well as your app to post/delete tweets. With OAuth it is limited posting/deleting tweets. This is not to say that Oauth solves all the problems of storing passwords.(It has its own problems of storing consumer secrets) If you are not storing password then basic auth over https from a trusted app is absolutely fine. Personally i believe OAuth does not have much to offer for desktop apps.The debate goes on. Sooner or later twitter is going to remove basic auth support. We have no choice but to move on. On Tue, Aug 11, 2009 at 8:27 PM, Bradley S. O'Hearne > wrote: Srikanth, Thank you for your thoughts -- good ones. Responses: But what if the app was developed by some thirdparty devs? you never know whether the password is stored or logged some where. I'm not sure who the "third party" is relative to -- if you are the user of an iPhone app, *every* app was developed by a third party. If you are the developer of the app, and you are worried about development you've farmed out to a third party, well, that's not an authentication issue -- that's a personnel / business problem. You shouldn't be publishing code which you aren't aware of what it does. I made reference to this in another thread, but when a user voluntarily downloads an iPhone app and puts it on their device, and then runs it, they've explicitly demonstrated a level of trust for that app. If they are concerned about it being a rogue app, then downloading the app, putting it on their device, and running it seems inconsistent with a true concern about it being a rogue app. But furthermore, let's assume there was some concern about password entry -- I do not see how OAuth saves you at all. You are still keying in your password within the app, in code that the developer of this so-called "rogue" app developed. The developer could be phishing with a spoof OAuth web page, but even if the OAuth page is authentic, the devel
[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone
For the case of a dedicated application on a rich mobile platform like iPhone, I agree that OAuth does not offer a particularly different user experience. It does, however, provide us at Twitter the information we need to provide detailed usage analytics back to developers, as well as the data we need to better understand our platform and help it grow. OAuth also provides a mechanism for users to revoke access to applications that aren't behaving as they expected; on the iPhone, removing a misbehaving application is as simple as deleting it, but for some non-technical users it may be helpful for them to visit their Twitter settings and see the list of applications they've authorized. We're working with our mobile team on improving the iPhone-optimized version of the OAuth workflow. It may not be an enormous improvement over password-based authentication, but once it's done, it certainly won't be a hinderance. Twitter is one of many companies moving to OAuth, and you can already find iPhone applications like TripIt that rely solely on OAuth for authentication. On Mon, Aug 10, 2009 at 14:16, Bradley S. O'Hearne wrote: > > All, > > I don't want to kick this subject to death, as there was a lengthy thread > on general OAuth vs. Basic auth -- I want to restrict this question strictly > to the scope of iPhone apps. Having pored over the OAuth vs. Basic > authentication process, I have a question, given the following assumptions: > > - The iPhone app is communicating directly with Twitter, i.e. not through > some third-party means. > > - The iPhone app requires authentication at the beginning of each > application runtime (i.e. each time the app is run the user has to type in > their password). > > - The password is cached only in memory, for the life of that specific > runtime (i.e. when the user quits the app, the password is released). > > - The password is NEVER persisted anywhere, i.e. never stored to disk. > > - All network communication with Twitter takes place over HTTPS. > > If all of those things are true in an iPhone app, how is OAuth superior in > any way to basic authentication from a security standpoint? Furthermore, > given having to introduce a foreign UI element and extra authentication > steps over the web, could OAuth even be considered inferior when evaluated > as a whole as an authentication means for the iPhone, when app branding, > integration, and ease of use are considered? > > Mind you, the purpose of this post is not in any way to incite a religious > war or stir the pot, it is to definitively establish the true pros and cons > of each authentication means within the specific use case of the iPhone > only. Many of the other OAuth / Basic auth threads are somewhat overridden > with personally charged statements that I'd rather ignore them. > > Anyway, your constructive views are most appreciated. > > Regards, > > Brad > > > -- Alex Payne - Platform Lead, Twitter, Inc. http://twitter.com/al3x
[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone
By third party i meant some one like 'TwitViewer' (some one who would pay and register their app in appstore and trick the users to believe in them but who do not work the way they were expected to ) <> NO. With OAuth you are not keying in your password with in the app. <> I have to agree with this particularly for desktop apps (But app store admins catch this.) <> Now assume your third party app is legitimate and supports basic auth and is storing password. If some one steals your iphone he could use your password (doesnt matter whether it is stored encrypted) as well as your app to post/delete tweets. With OAuth it is limited posting/deleting tweets. This is not to say that Oauth solves all the problems of storing passwords.(It has its own problems of storing consumer secrets) If you are not storing password then basic auth over https from a trusted app is absolutely fine. Personally i believe OAuth does not have much to offer for desktop apps.The debate goes on. Sooner or later twitter is going to remove basic auth support. We have no choice but to move on. On Tue, Aug 11, 2009 at 8:27 PM, Bradley S. O'Hearne wrote: > Srikanth, > Thank you for your thoughts -- good ones. Responses: > > > But what if the app was developed by some thirdparty devs? you never know > whether the password is stored or logged some where. > > > I'm not sure who the "third party" is relative to -- if you are the user of > an iPhone app, *every* app was developed by a third party. If you are the > developer of the app, and you are worried about development you've farmed > out to a third party, well, that's not an authentication issue -- that's a > personnel / business problem. You shouldn't be publishing code which you > aren't aware of what it does. > > I made reference to this in another thread, but when a user voluntarily > downloads an iPhone app and puts it on their device, and then runs it, > they've explicitly demonstrated a level of trust for that app. If they are > concerned about it being a rogue app, then downloading the app, putting it > on their device, and running it seems inconsistent with a true concern about > it being a rogue app. > > But furthermore, let's assume there was some concern about password entry > -- I do not see how OAuth saves you at all. You are still keying in your > password within the app, in code that the developer of this so-called > "rogue" app developed. The developer could be phishing with a spoof OAuth > web page, but even if the OAuth page is authentic, the developer could still > intercept keyboard events and capture your password that way. > > That said, it seems that the real danger on the iPhone is storing a > password, not having the device as a whole password protected, and then > losing your device. Someone can then go into your phone, and Twitter related > app, and have direct access to your account (which I believe would still be > a danger with OAuth tokens). So the solution seems to not be the means of > authentication, it seems to be whether a password is stored or not, and > whether it is transmitted securely. > > Brad > > On Aug 11, 2009, at 12:02 AM, srikanth reddy wrote: > > My thoughts > > OAuth wasn't meant for Desktop apps. Its for third party apps (consumers) > who try to request a protected resource from a service provider on behalf > of end users. Typically a consumer offers one kind of service and a service > provider offers a different service. As you know the advantage of OAuth is > you are not giving away your password to consumers. > > For desktop apps (iphone apps) it is perfectly fine to use basic auth over > https But what if the app was developed by some thirdparty devs? you never > know whether the password is stored or logged some where. There is always an > element of risk. OAuth solves this problem to a little extent. You are > giving your password only to twitter and the consumer/app gets the token. > Even if a rogue consumer steals this token you at least have the option of > revoking the access to this consumer. But if password is stolen you cannot > do anything. > > As you know OAuth primarily deals with Authorization and Authentication is > secondary. So its not a question of comparing it with Basic Auth over HTTPS. > > These are just my thoughts. > > Srikanth > > On Tue, Aug 11, 2009 at 2:46 AM, Bradley S. O'Hearne < > brad.ohea...@gmail.com> wrote: > >> >> All, >> >> I don't want to kick this subject to death, as there was a lengthy thread >> on general OAuth vs. Basic auth -- I want to restrict this question strictly >> to the scope of iPhone apps. Having pored over the OAuth vs. Basic >> authentication process, I have a question, given the following assumptions: >> >> - The iPhone app is communicating directly with Twitter, i.e. not through >> some third-party means. >> >> - The iPhone app requires authentication at the beginning of each >> application runtime (i.e. each time the app is run the user has to type in >> their pas
[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone
Srikanth, Thank you for your thoughts -- good ones. Responses: But what if the app was developed by some thirdparty devs? you never know whether the password is stored or logged some where. I'm not sure who the "third party" is relative to -- if you are the user of an iPhone app, *every* app was developed by a third party. If you are the developer of the app, and you are worried about development you've farmed out to a third party, well, that's not an authentication issue -- that's a personnel / business problem. You shouldn't be publishing code which you aren't aware of what it does. I made reference to this in another thread, but when a user voluntarily downloads an iPhone app and puts it on their device, and then runs it, they've explicitly demonstrated a level of trust for that app. If they are concerned about it being a rogue app, then downloading the app, putting it on their device, and running it seems inconsistent with a true concern about it being a rogue app. But furthermore, let's assume there was some concern about password entry -- I do not see how OAuth saves you at all. You are still keying in your password within the app, in code that the developer of this so- called "rogue" app developed. The developer could be phishing with a spoof OAuth web page, but even if the OAuth page is authentic, the developer could still intercept keyboard events and capture your password that way. That said, it seems that the real danger on the iPhone is storing a password, not having the device as a whole password protected, and then losing your device. Someone can then go into your phone, and Twitter related app, and have direct access to your account (which I believe would still be a danger with OAuth tokens). So the solution seems to not be the means of authentication, it seems to be whether a password is stored or not, and whether it is transmitted securely. Brad On Aug 11, 2009, at 12:02 AM, srikanth reddy wrote: My thoughts OAuth wasn't meant for Desktop apps. Its for third party apps (consumers) who try to request a protected resource from a service provider on behalf of end users. Typically a consumer offers one kind of service and a service provider offers a different service. As you know the advantage of OAuth is you are not giving away your password to consumers. For desktop apps (iphone apps) it is perfectly fine to use basic auth over https But what if the app was developed by some thirdparty devs? you never know whether the password is stored or logged some where. There is always an element of risk. OAuth solves this problem to a little extent. You are giving your password only to twitter and the consumer/app gets the token. Even if a rogue consumer steals this token you at least have the option of revoking the access to this consumer. But if password is stolen you cannot do anything. As you know OAuth primarily deals with Authorization and Authentication is secondary. So its not a question of comparing it with Basic Auth over HTTPS. These are just my thoughts. Srikanth On Tue, Aug 11, 2009 at 2:46 AM, Bradley S. O'Hearne > wrote: All, I don't want to kick this subject to death, as there was a lengthy thread on general OAuth vs. Basic auth -- I want to restrict this question strictly to the scope of iPhone apps. Having pored over the OAuth vs. Basic authentication process, I have a question, given the following assumptions: - The iPhone app is communicating directly with Twitter, i.e. not through some third-party means. - The iPhone app requires authentication at the beginning of each application runtime (i.e. each time the app is run the user has to type in their password). - The password is cached only in memory, for the life of that specific runtime (i.e. when the user quits the app, the password is released). - The password is NEVER persisted anywhere, i.e. never stored to disk. - All network communication with Twitter takes place over HTTPS. If all of those things are true in an iPhone app, how is OAuth superior in any way to basic authentication from a security standpoint? Furthermore, given having to introduce a foreign UI element and extra authentication steps over the web, could OAuth even be considered inferior when evaluated as a whole as an authentication means for the iPhone, when app branding, integration, and ease of use are considered? Mind you, the purpose of this post is not in any way to incite a religious war or stir the pot, it is to definitively establish the true pros and cons of each authentication means within the specific use case of the iPhone only. Many of the other OAuth / Basic auth threads are somewhat overridden with personally charged statements that I'd rather ignore them. Anyway, your constructive views are most appreciated. Regards, Brad
[twitter-dev] Re: OAuth vs. Basic authentication strictly on iPhone
My thoughts OAuth wasn't meant for Desktop apps. Its for third party apps (consumers) who try to request a protected resource from a service provider on behalf of end users. Typically a consumer offers one kind of service and a service provider offers a different service. As you know the advantage of OAuth is you are not giving away your password to consumers. For desktop apps (iphone apps) it is perfectly fine to use basic auth over https But what if the app was developed by some thirdparty devs? you never know whether the password is stored or logged some where. There is always an element of risk. OAuth solves this problem to a little extent. You are giving your password only to twitter and the consumer/app gets the token. Even if a rogue consumer steals this token you at least have the option of revoking the access to this consumer. But if password is stolen you cannot do anything. As you know OAuth primarily deals with Authorization and Authentication is secondary. So its not a question of comparing it with Basic Auth over HTTPS. These are just my thoughts. Srikanth On Tue, Aug 11, 2009 at 2:46 AM, Bradley S. O'Hearne wrote: > > All, > > I don't want to kick this subject to death, as there was a lengthy thread > on general OAuth vs. Basic auth -- I want to restrict this question strictly > to the scope of iPhone apps. Having pored over the OAuth vs. Basic > authentication process, I have a question, given the following assumptions: > > - The iPhone app is communicating directly with Twitter, i.e. not through > some third-party means. > > - The iPhone app requires authentication at the beginning of each > application runtime (i.e. each time the app is run the user has to type in > their password). > > - The password is cached only in memory, for the life of that specific > runtime (i.e. when the user quits the app, the password is released). > > - The password is NEVER persisted anywhere, i.e. never stored to disk. > > - All network communication with Twitter takes place over HTTPS. > > If all of those things are true in an iPhone app, how is OAuth superior in > any way to basic authentication from a security standpoint? Furthermore, > given having to introduce a foreign UI element and extra authentication > steps over the web, could OAuth even be considered inferior when evaluated > as a whole as an authentication means for the iPhone, when app branding, > integration, and ease of use are considered? > > Mind you, the purpose of this post is not in any way to incite a religious > war or stir the pot, it is to definitively establish the true pros and cons > of each authentication means within the specific use case of the iPhone > only. Many of the other OAuth / Basic auth threads are somewhat overridden > with personally charged statements that I'd rather ignore them. > > Anyway, your constructive views are most appreciated. > > Regards, > > Brad > > >
