Okay, I think we really need to expand on something...
oAuth was never designed to promote any app developer to bypass the built-in
web browser (from an App) -- (ie: using UIWebView). There are many reasons for
this. If one wanted to steal usernames and passwords, it is VERY easy to
simulate the look and feel of Twitter's login page for oAuth in order to take
the username and password of the person logging in. Indeed, there is nothing
to stop anyone from doing this (directing the user toward their own website),
getting the username and password and -- in the background -- logging the user
into Twitter using oAuth, getting the token and proceeding as normal in their
app. Later (in this scenario) they could do something insidious with the
username/password combo.) Thus oAuth -- used in this manner (in a UIWebView)
bypasses one major reason oAuth was developed. In other words, using the
UIWebview is insecure 'cos the user does not have the built-in notifications
(some would say guarantees -- although I don't see them as guarantees) that a
built-in web browser offers. That is, the UIWebView does not necessarily show
the URL line with the REAL url that the user is being referred to. I can
easily put a UITextField at the top of any UIWebView, put the Twitter URL in
that and displaying a lock symbol somewhere on my UIWebView. This "looks" like
the user is going to the right place but indeed I may be doing a
man-in-the-midle type attack.
The only security offered by oAuth used in this method is that you are
exchanging a token once for each function you are asking Twitter to do. One of
the primary reasons oAuth was developed was to ensure that the app/website
NEVER got access to the user's password. The other was that the
username/password was passed in the URL, thus being logged in many companies
firewalls, filters and sniffers -- not to mention Twitter's own access_logs
(not known -- assumed).
Here is my main gripe: As someone earlier stated: The only danger with
Twitter's password being captured by the app is that you can post as this user
to Twitter and associated sites. The main worry to me is not that someone can
post as me (to Twitter) -- it is that people like my parent may use the same
username/password combo on Twitter that they do on their banking website. BUT
you cannot save people from their own stupidity.
The time for discussing oAuth vs xAuth is over. Twitter has decided -- and in
my opinion they have offered us a valid alternative to oAuth for Apps. xAuth
is here, it is a valid compromise for the UX in Apps and is not allowed for Web
Apps.
That is good enough for me.
Jann
On May 31, 2010, at 2:09 AM, Rich wrote:
>
> I consider it completely the opposite and that the oauth workflow is
> more secure than the xauth one. To me seeing the Twitter website login
> page shows me that only Twitter will see my login information and not
> the client app itself
>
> An xauth workflow the app should only pass it on in exchange for an
> oauth token but there is nothing to stop them harvesting the
> information in the meantime
>
> Running the oauth workflow on the iPhone is not painful and can all be
> done seamlessly from within your app itself. The user won't ben
> confused either if you do it right
>
>
> On May 30, 6:15 pm, Jann Gobble <janngob...@gmail.com> wrote:
>> Okay, please tell me you know that I can create an app with a UIWebView that
>> will take that password you type in faster than anything.
>>
>> It is NOT secure. This is my problem with oAuth. The work-arounds cause a
>> false sense of security. oAuth was NEVER supposed to be used this way. If
>> the user does not trust the app, they should definitely not trust the
>> developer that puts a UIWebView in it -- it is too easy to do a
>> man-in-the-middle. oAuth fits in well with webapps, not iPhone apps.
>>
>> Anyway, this was all hashed out internally to Twitter -- that is why they
>> came up with xAuth.
>>
>> :)
>>
>> Jann
>>
>> On May 30, 2010, at 3:50 AM, Rich wrote:
>>
>>
>>
>>> You don't have to go from app to browser, embed a UIWebView and then
>>> in
>>
>>> - (BOOL)webView:(UIWebView *)webView shouldStartLoadWithRequest:
>>> (NSURLRequest *)request navigationType:
>>> (UIWebViewNavigationType)navigationType {
>>
>>> Look for your callback URL and read the query string and you'll be
>>> authorised, then just remove the UIWebView and use your application.
>>> The user never has to leave your app.
>>
>>> Then the user gets MORE security that xAuth because they can see they
>>> are logging in on Twitter.com and not giving their password to an
>>> arbitrary application, which could still save their password without
>>> their knowledge.
>>
>>> On May 30, 8:35 am, Jann Gobble <janngob...@gmail.com> wrote:
>>>> The requirement for users to go from app to browser to app is untenable
>>>> for many of my users. It is a major change to go from app to Safari and
>>>> back to app. Many users actually think that it the app is less secure
>>>> (rightly or wrongly) because they have to exit it -- and go to the web --
>>>> in order to login.
>>
>>>> Indeed, many of them do not understand the permissions that the oAuth
>>>> system asks for when they get sent to the Twitter page. Unfortunately
>>>> with a phone like the iPhone you are dealing with many many users who are
>>>> new to mobile devices in general and just wish to use twitter from within
>>>> their favorite apps without the complications.
>>
>>>> Would you say that oAuth is good enough for Twitterific or Chirpie,
>>>> Tweetie? Well, they are using xAuth. All I wish to do is to provide my
>>>> users with identical (and what they see is easy -- and safe) method of
>>>> using Twitter. xAuth provides this. oAuth does not. Many users prefer a
>>>> seamless experience to that of adopting a protocol that causes such a
>>>> jarring user experience -- regardless of the perceived safety of oAuth
>>>> over xAuth. Safety of one over the other comes down to how much you trust
>>>> the app. It no longer comes down to how much you trust Basic Auth.
>>
>>>> I would have no problem if there was an even playing field where we could
>>>> all have our app "signatures" in the Tweet -- and all have the same user
>>>> experience where logins and permissions are concerned. This is not the
>>>> case.
>>
>>>> Thanks for your input, though.
>>
>>>> Jann
>>
>>>> On May 30, 2010, at 12:03 AM, Rich wrote:
>>
>>>>> You don't need xAuth to develop an iPhone app, oAuth workflow works
>>>>> just fine.
>>
>>>>> Indeed I though xAuth was designed for clients without a decent mobile
>>>>> browser which isn't the case on the iPhone
>>
>>>>> On May 29, 2:08 am, Jann <janngob...@gmail.com> wrote:
>>>>>> I sent an email in to api@ this week. Got back a case # which, when
>>>>>> clicked, requires me to login. It then tells me that the case
>>>>>> #1008949does not exist.
>>
>>>>>> So, I logged in under the twitter account that created the app and
>>>>>> created another ticket. Got another ticket #1009859. I am now
>>>>>> wondering how long this is supposed to take. (if the first one is
>>>>>> invalid, then my new support case is now over 900 cases farther down
>>>>>> in the queue. :(
>>
>>>>>> Does anyone have any ideas? I have seen (when searching on google)
>>>>>> that some people say it takes upwards of a week to get the approval.
>>>>>> I am stuck however because I cannot even test my iPhone app using this
>>>>>> method. (I am usinghttp://aralbalkan.com/3133(xAuthTwitterEngine) to
>>>>>> implement and I can see no method to begin even testing using my own
>>>>>> account.
>>
>>>>>> Shouldn't there be some way to (at least) test your app using the
>>>>>> username and password that was used to create the "Application" in
>>>>>> question?
>>
>>>>>> Please give some insight. Maybe I am missing something stupid.
>>
>>>>>> Thanks!
>>
>>>>>> Jann
