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 <brad.ohea...@gmail.com
> 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 )
<<You are still keying in your password within the app, in code
that the developer of this so-called "rogue" app developed. >>
NO. With OAuth you are not keying in your password with in the app.
<<the developer could still intercept keyboard events and capture
your password that way. >>
I have to agree with this particularly for desktop apps (But app
store admins catch this.)
<<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).>>
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:
<snip>
But what if the app was developed by some thirdparty devs? you
never know whether the password is stored or logged some where.
</snip>
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 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
--
Internets. Serious business.