Android: [OAuth2] Improve trust/security when login in embedded web view

[michaelstingl]

As discussed at the ownCloud Conference 2017, there some best practice recommendations to improve trust and security when user login in the embedded web view.

This is is an article from Carnegy Mellon CERT that describes the motivation:
https://insights.sei.cmu.edu/cert/2016/08/the-risks-of-google-sign-in-on-ios-devices.html

Another article describes possible solutions with a contribution from Google:
https://www.pingidentity.com/en/blog/2016/03/10/using_appauth_to_enable_your_apps_with_mobile_sso.html

There is also a video recording available from the Google Team:
https://youtu.be/DdQTXrk6YTk

You will find very detailed information in a new IETF draft from OAuth Working Group:
https://tools.ietf.org/html/draft-ietf-oauth-native-apps (June 9, 2017)
https://tools.ietf.org/html/rfc8252 (October 2017)

@davivel @davigonz Could you check how the ownCloud Android client could be improved following the linked recommendation?

Related: https://github.com/owncloud/ios/issues/942

00008274

[davivel]

Reading...

[davivel]

Summarizing, the main idea there is: "do not use webviews in your app to authenticate the user".

And the alternatives available are:

• redirect the log-in to the user web-browser
• redirect the log-in to an app/service/framework owned by the authentication provider

IMHO, the idea is not about improving security itself, but about granting to the user that the security is real. In the end, the OC app is not storing the credentials when SAML or OAuth are used; delegating the log-in to a web browser or an external app would not improve that, just would demonstrate to the user that there is no way we sniff them from the embedded web view.

[michaelstingl]

Not exactly. AppAuth would be part of your app, but wouldn't look like DIY and it would have an option to leave your app and use your system browser instead for login.

[michaelstingl]

For Android, this would mean, use AppAuth-Android instead of our selfmade web view.

[codedsun]

I want to contribute! need help..

[michaelstingl]

FYI: just updated the the link to a new version of the RFC

[davigonz]

Hi @codedsun , glad to see that you are interested in contributing here. One of the security improvements we've talked about is to include an option to use the system browser instead of the webview during authentication with OAuth2, so that the user verifies the url and check that is a real and trusty one.

You could start your contribution by thinking about where this option would appear (the webview itself for example) and start to implement the behaviour (opening the external browser and handle all the introduced data). If you need some help, just ping me. :wink:

[nasli]

@codedsun For Android review Chrome Custom Tabs and replace WebViews. Great tips on the video

[michaelstingl]

I also don’t understand yet what else https://github.com/openid/AppAuth-Android would help us besides only using Chrome Custom Tabs. Is there more we could use?

[codedsun]

So what exactly has to be implemented?
Web View or Chrome custom tabs?

Kindly guide me further so that I can pick up and complete more issues.

[davigonz]

I also don’t understand yet what else https://github.com/openid/AppAuth-Android would help us besides only using Chrome Custom Tabs. Is there more we could use?

@michaelstingl I've been skimming the AppAuth documentation and what basically does is map the requests and responses of OAuth2 using different classes, apart from including methods to assist with common tasks like refreshing a token or performing actions with fresh tokens. Besides, it includes Custom Tabs for authorization requests.

IMHO, AppAuth would have been a good option if we hadn't implemented OAuth2 support by our own; using it in this moment supposes getting rid of great part of our OAuth2 implementation, delegating it to AppAuth.

Related to custom tabs, I think that is a change that we should face not only for OAuth2 but also for SAML, since we are showing a webview for both cases and the security issues are there.

[davigonz]

Hi @codedsun , the idea is to replace the WebView we are currently using for OAuth2 authorization requests with Chrome Custom Tabs.

There are some links related to Chrome Custom Tabs documentation in comments above but I paste them here again:

• Guide including implementation: https://developer.chrome.com/multidevice/android/customtabs
• Video with some tips: https://youtu.be/DdQTXrk6YTk

[codedsun]

@davigonz Ok ! I will be sending the PR, by implementing the chrome custom tabs.

[codedsun]

@davigonz I will be sending the PR soon , my laptop broked up so couldn't work! and will ping u if stuck :)

[davigonz]

I will be sending the PR soon , my laptop broked up so couldn't work! and will ping u if stuck :)

@codedsun ok, no problem!

[sd1998]

Is anyone working on this?

[sd1998]

@davigonz The Chrome Custom Tabs dependency required minSdkVersion 15 and the app has minSdkVersion as 14 should I change it?

[jesmrec]

no one is working on this yet, so if you want to contribute, you are welcome!!

@davigonz is off for some days, but he will be pleasant to help you once he is back.

[davigonz]

The Chrome Custom Tabs dependency required minSdkVersion 15 and the app has minSdkVersion as 14 should I change it?

Hi @sd1998 , you can import libraries ignoring the app minimum SDK version by using tools:overrideLibrary option.

In our case, something like this should be enough:

<uses-sdk android:minSdkVersion="14" android:targetSdkVersion="26" /> tools:overrideLibrary="android.support.customtabs"

Could you try out it? Thanks

[SamuAlfageme]

Linking here the conclusions drawn from dealing with webview sandboxes and their risks (ref. https://github.com/owncloud/oauth2/pull/103): https://github.com/owncloud/core/pull/30365#issuecomment-365335101

[michaelstingl]

As I understand, Chrome Custom Tabs would have own cookies that can’t be accessed from oC Android app, and Chrome Custom Tabs also can’t access cookies from oC Android app. They would be totally separated, same as the desktop sync client and the default system browser. It should work exactly the same way.

[jesmrec]

Currently, android app is not using webview cookies after the auth process. Chrome Custom tabs is supposed to do the same, of course.

[theScrabi]

So I was about to implement this, however we have a problem. Chrome custom tabs is called Chrome custom tabs its based on chrome, and thus needs it to be installed. What should we do when chrome is not installed? Should we keep using WebView as a fall back, or should we force the user to install chrome (might piss off some FLOSS people).

AppAuth solves this problem by using a Black/Whitelist for certain browsers, and than use customized interfaces for each browser to be compatible to them. We can't do that since the code we'd have to write was huge. However maybe we can get advantage of AppAuth just for login not for the whole oauth thing.

[michaelstingl]

maybe we can get advantage of AppAuth just for login not for the whole oauth thing.

sounds interesting

[theScrabi]

maybe we can get advantage of AppAuth just for login not for the whole oauth thing.

Well it seems we'd hat to replace the current setup with AppAuth if we wanted to do that. Well...
I compiled a list of apps that allow custom tabs. Maybe we could ask the user to install one of these apps if CustomTab is not available.