iPhone UIWebView, OAuth and User-Agent trust

[Darren Bounds (Cliqset)]

Recently my colleague and I began looking a little closer at the
iPhone SDK in an effort to research how to best incorporate an OAuth
authorization model. Naturally UIWebView was front and center as it
currently provides the only method (at least that I'm aware of) for an
application to transition between itself and the browser without
requiring the user to re-launch the application. While at a glance,
this appeared ideal for OAuth, I became concerned when it was apparent
that all interaction, including HTTP request/response data, would be
fully accessible to the parent application via UIWebView.

From my perspective, one of the greatest architectural features of the
OAuth and OpenID protocols is the complete absence of any requirement
the user place trust in the application they're authorizing or
authenticating to. This doesn't appear to be possible through
UIWebView as the application has the ability to capture any and all
interaction, regardless of whether SSL is employed.

I'm curious if the group has any thoughts or greater insight into
UIWebView security model and its impact on user-agent trust and
privacy on the iPhone. Hopefully I've missed something.


References:

UIWebView
https://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIWebView_Class/Reference/Reference.html#//apple_ref/doc/uid/TP40006950-CH3-SW11

UIWebViewDelegate
https://developer.apple.com/iphone/library/documentation/UIKit/Reference/UIWebViewDelegate_Protocol/Reference/Reference.html

NSURLRequest
https://developer.apple.com/iphone/library/documentation/Cocoa/Reference/Foundation/Classes/NSURLRequest_Class/Reference/Reference.html#//apple_ref/doc/c_ref/NSURLRequest


Thanks,

Darren

[Chris Messina]

Just to chime in here... there's a curious three-way balance here, between real security, user experience and providing a solution that developers will stomach.

On the security front, I agree with you. Opening up the external browser from an app that wants to do OAuth is the least "deviant" way of authorizing an app without providing that app with your username and password — either directly or through a WebView. However, developers and designers complain (and users might get confused as well) that this is a jerky user experience compared with just asking for their credentials directly.

A compromise is, as you suggested, for the app to use a WebView with the URL bar shown *within* the app. There's nothing to verify that the URL bar isn't being spoofed or that the data isn't being bifurcated back to the developer through a backchannel. But at least the user stays within a single application and the flow is smoother, and, if the developer is honest, she never sees the user's interaction on the Service Provider's site.

It seems to me that developing an open source library for dealing with OAuth on the iPhone provides us a couple benefits... for one thing, for those developers who use it, there is some visibility into the security of the code. Another thing is that we could collaborate on better user experiences.

Hence this list. So, to answer your question, yes, I believe we'd thought about it a bit, but don't exactly have answers. I've written some posts about OpenID and mobile, however, that might be relevant:

http://factoryjoe.com/blog/2008/10/28/openid-usability-is-not-an-oxymoron/

http://factoryjoe.com/blog/2008/01/13/the-openid-mobile-experience/

http://factoryjoe.com/blog/2008/05/17/the-openid-mobile-experience-part-ii/

http://factoryjoe.com/blog/2008/10/30/lightweight-access-pins-a-modest-proposal-for-enabling-openid-in-desktop-and-mobile-apps/

http://factoryjoe.com/blog/2007/07/09/openid-on-the-iphone/

http://factoryjoe.com/blog/2008/07/11/oauth-for-the-iphone-pownceapp/

Chris

--
Chris Messina
Citizen-Participant &
 Open Web Advocate-at-Large

factoryjoe.com # diso-project.org
citizenagency.com # vidoop.com
This email is:   [ ] bloggable    [X] ask first   [ ] private

[Darren Bounds]

Thanks Chris,

While I agree there has to be a compromise, I'm not sure 'user trust'
is the place to make it.

Let's face it, OpenID and OAuth in their current form don't lend
themselves to the greatest UX. It seems to me the only reason to put a
user through this 302 bounce around is to protect the integrity of the
users' authentication material. If we're going to bend on the security
angle, that's fine, but it would make sense to then take a step or two
back, look at the specs, and redefine them with these new security
assumptions in mind. The result will surely be a much improved UX
that's much easier for the developer to stomach.

Darren

--

Thank you,
Darren Bounds

[Chris Messina]

Believe you me, I agree. This is the one issue really keeping Google from becoming an OpenID relying party and has a lot to do with their worked on Federated Login UX:

http://sites.google.com/site/oauthgoog/Home

http://sites.google.com/site/oauthgoog/UXFedLogin

http://sites.google.com/site/oauthgoog/UXFedLogin/nobrowser

I think the other thing to point out is that there is an assumption of trust (currently) when users use desktop/native applications... (moreso than web apps, I'd imagine, but of course it depends on circumstances). Developers probably also prefer to think of themselves as trustworthy, though more and more seem reluctant to touch user account credentials.

Some people have made the argument that being in a native client experience is kind of a point of no return — that the user will trust the experience implicitly and with abandon. The hoops that people currently have to jump through probably seem both not worth the hassle and might even seem like insecure experiences.

I know MySpace and Google (possibly others) are doing user testing in this area. Bottom line, where we've come from in this area is not where we're going; but where we're going is still somewhat foggy owing the difficulty of balancing security, familiarity, convenience, ease of use, cost of implementation and coping with the fragmentation of user identity.

I'm of the opinion that with stronger identity, a lot of this stuff gets easier, but we've got a ways to go there as well.

Chris

[Karl Adam]

Chris has already covered the UX issues faced with an inline browser
approach and has also touched on the fact that for desktop and mobile
application that are downloaded and installed the rules are already
different as the the trust model the user employs when interacting
with them.

On the engineering side however, there is no way to keep the parent
application unaware of what the UIWebView is loading regardless of the
security context associated with the url. You're basically going to
have to be willing to trust the software engineer on the iPhone to use
it responsibly. MPOAuth has an iPhone sample app that I'm in the midst
of updating to demonstrate the inline browser authentication and even
leverage the fact that I can watch the url load requests, to intercept
when it's finished and tries to load the callback url to return the
control back to the main application popping the UIWebView off the
view controller stack for what is a much less abrupt UX experience on
the iPhone.

On the desktop you can easily pop the user out to their preferred
browser, but even here I think UX would also be improved by the
ability to do the authentication inline personally.

_Karl

[Zsombor Szabó]

Hey Darren,

I was also fighting this issue and gave a lot of thought. I chose the mobile Safari app instead using an UIWebView which smells like a phishing scam as you pointed out.

There is a way to provide smooth user experience by using URL schemes and saving application state when quitting:

At the access token authorization step (http://oauth.net/core/1.0/#auth_step2) you call [[UIApplication sharedApplication] openURL:loginURL];

That closes your application and opens the mobile Safari app. Be sure to save your application's state in your UIApplication delegate - (void)applicationWillTerminate:(UIApplication *)application method. 

loginURL should have the access token (oauth_token) AND a callback (oauth_callback) as parameter. This way the service provider knows where to direct your browser upon successful authorization. If you register on the iPhone an URL scheme for you application, like for example x-com-yourdomain-iphoneapp:// and pass the "x-com-yourdomain-iphoneapp://auth_token_ready" string as the oauth_callback parameter, then after successful authentication the mobile Safari app will be closed and your application will start again and is asked to handle an URL call with the response token. It can handle this URL call in the - (BOOL)application:(UIApplication *)application handleOpenURL:(NSURL *)url method where you can restore the application's previous state.

More to read:

http://fireeagle.yahoo.net/developer/documentation/oauth_best_practice

http://furbo.org/2008/10/01/redacted/

Regards,

Zsombor

[Karl Adam]

The only problem with the URI scheme approach is that it doesn't sidestep the actual problem which is the bouncing from application to application and then finally coming back to the main application. The in application UIWebView will work with the same URI approach you highlighted with the added benefit of never leaving the application.

Also, you should be sure to make a completely custom URI for this specific purpose as the iPhone does not yet provide a robust way of controlling what applications are responsible for default URI handlers or multiple handlers for URIs, at this point the behavior is still undefined. So, the suggested x-com-domain-iphoneapp:// URI format should be followed.

_Karl