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 

That is good enough for me.


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

Reply via email to