GREE, one of the biggest gaming platform which I’m working for, provides both iOS and Android SDKs.
Our iOS SDK had been using Safari for OAuth dance before. However, Apple started to reject lots of gaming apps using our SDK because of external browser launch. So we had switched to embedded WebView, unfortunately. Our Android SDK uses external browser. I believe launching external browser is Google’s recommendation. nov > On May 12, 2015, at 22:58, Dick Hardt <dick.ha...@gmail.com> wrote: > > My guess is that these apps use an embedded web view because Apple told them > to do that, just like they told me. > > Anyone have insight in what happens in the Android world? > > On Tue, May 12, 2015 at 2:28 AM, Aaron Parecki <aaron.pare...@gmail.com > <mailto:aaron.pare...@gmail.com>> wrote: > Yeah, unfortunately a ton of apps use embedded web views. With iOS 8 at least > there is now a way to use a web view in a different security context. I also > thought there was a slightly different UI for apps that bring up the action > sheets, but I can't find an example on my phone of how that looks. The > closest I can find is this example of sharing a URL with the Pinterest app. > However it would still require some extra work on Apple's part to make sure > the user can be sure this is an Apple-provided dialog and not crafted from > within the app. > > <pinterest_iphone_share_apps_screens.jpg> > > On Tue, May 12, 2015 at 12:35 AM, Dick Hardt <dick.ha...@gmail.com > <mailto:dick.ha...@gmail.com>> wrote: > Aaron: After some googling around, I see a number of SDKs use embedded web > views for logging in, and have been doing that for a while. I'm not sure how > a UIRemoteViewController would give the user assurance they are really on > Google or LinkedIn that would be any different than launch Safari. > > Given the curtness of the response and the reference to 10.6 in the guide, I > think they just think it is a bad user experience to launch Safari and don't > understand the security implications. > > Joost: I also am shocked. Trivial to MITM the page from any site. > > > On Mon, May 11, 2015 at 2:55 PM, Aaron Parecki <aaron.pare...@gmail.com > <mailto:aaron.pare...@gmail.com>> wrote: > I haven't quite done enough research to be sure, but it sounds like there is > a way to open a WKWebView sheet in a similar way to opening the mail sheet, > where your app doesn't actually have access to the window that is opened. I > believe this is referred to as a UIRemoteViewController. There are some posts > about it here: > http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/ > <http://oleb.net/blog/2012/10/remote-view-controllers-in-ios-6/> > http://chris.cm/ios-8-remote-view-controllers/ > <http://chris.cm/ios-8-remote-view-controllers/>Given the response you got, I > wouldn't be surprised if UIRemoteViewController becomes an official API and > they are pre-emptively rejecting apps that don't use it. I guess we'll fine > out on June 8th ;-) > > --- > Aaron > http://aaronparecki.com <http://aaronparecki.com/> > > > On Mon, May 11, 2015 at 10:12 PM, Joost van Dijk <vandijk.jo...@gmail.com > <mailto:vandijk.jo...@gmail.com>> wrote: > I am stunned. What Apple is saying here is that we shouldn’t bother using > OAuth2. > > We might as well revert to asking for the user’s Google/LinkedIn credentials > directly. When we make the login page sufficiently familiar, the user won’t > be able to tell the difference anyway. > —Joost > >> On 11 May 2015, at 18:54, Dick Hardt <dick.ha...@gmail.com >> <mailto:dick.ha...@gmail.com>> wrote: >> >> Here is what I received from the Appeal Review Board: >> >> (highlighting is mine) >> >> Hello Dick, >> >> We are writing to let you know the results of your appeal for your app, >> Bubbler Mobile. >> >> The App Review Board evaluated your app and determined that the original >> rejection feedback for the current version of your app is valid. Your app >> does not comply with: >> >> 10.6: Apple and our customers place a high value on simple, refined, >> creative, well thought through interfaces. They take more work but are worth >> it. Apple sets a high bar. If your user interface is complex or less than >> very good it may be rejected >> >> Upon further investigation, we found that your app takes the user out to >> Safari in order to login with Google and Linkedin, which is not in >> compliance with the App Store Review Guidelines. While we understand your >> intend to launch to Safari for login provides a better user experience, it >> is not in compliance with the App Store Review Guidelines. The user should >> be able to log into Google and Linkedin without opening Safari first within >> the app. Please provide users with a way to login with Google and Linkedin >> in the app. >> >> Therefore, your app will not be posted to the App Store at this time. >> >> We hope you will consider making the necessary changes to be in compliance >> with the App Store Review Guidelines and will resubmit your revised binary. >> >> Best regards, >> Nicki >> App Review Board >> >> On Fri, May 8, 2015 at 5:30 PM, Nat Sakimura <sakim...@gmail.com >> <mailto:sakim...@gmail.com>> wrote: >> Thanks Dick. >> OIDF is also trying to write a white paper why in-app browser for this >> purpose is a bad idea. >> >> =nat via iPhone >> >> 2015/05/09 4:28、Dick Hardt <dick.ha...@gmail.com >> <mailto:dick.ha...@gmail.com>> のメッセージ: >> >>> Glad to know I was not missing something. >>> >>> I explained all the logic in my first response to the reviewer. Next >>> response was to comply with 10.6 >>> >>> I have filed an appeal. Will keep list updated. >>> >>> Aaron: the LinkedIn API claw back really sucks. Facebook turned down APIs >>> earlier than v2 last month, and now there is little profile data from them. >>> Getting data out of the silos has gotten much tougher. >>> >>> >>> On Fri, May 8, 2015 at 7:46 PM, Joost van Dijk <vandijk.jo...@gmail.com >>> <mailto:vandijk.jo...@gmail.com>> wrote: >>> This is indeed very bad news. Not just because we are developing apps that >>> use the same approach, but also because we have declared in-app browsers to >>> be Bad Practice when used for authentication because of the reasons you >>> described. >>> >>> Furthermore, it just won't work. Our OAuth authorization server >>> authenticates to an identity federation where very diverse authentication >>> methods are used, such as TLS client authentication. An app won't have >>> access to the private key needed to authenticate when using an in-app >>> browser: you really need to open the platform browser for this to work. >>> >>> Cheers, >>> >>> -- >>> Joost >>> >>> On 08 May 2015, at 18:21, Dick Hardt <dick.ha...@gmail.com >>> <mailto:dick.ha...@gmail.com>> wrote: >>> >>>> I have an app that is was submitted to TestFlight that was rejected for >>>> opening up Safari for getting authorization from Google or LinkedIn. >>>> >>>> Apple wants me to load the Google or LinkedIn page with an in-app browser >>>> to comply with >>>> >>>> 10.6 - Apple and our customers place a high value on simple, refined, >>>> creative, well thought through interfaces. They take more work but are >>>> worth it. Apple sets a high bar. If your user interface is complex or less >>>> than very good, it may be rejected >>>> >>>> I'm thinking this is crazy >>>> >>>> The user experience is better bouncing to Safari as it: >>>> >>>> 1) clearly signals to the user that they are providing their credentials >>>> to Google or LinkedIn >>>> >>>> 2) Google and LinkedIn can pre-fill the username if they have previously >>>> used the browser at either site >>>> >>>> 3) If they Safari has their credentials, Safari can fill them in at Google >>>> / LinkedIn >>>> >>>> From a security point of view, the in-app webview has >>>> >>>> 1) NO signal to the user they are providing their credentials to LinkedIn >>>> or Google. >>>> >>>> 2) Looks like a new browser instance to LinkedIn and Google rather than an >>>> already known device. >>>> >>>> I'm surprised Apple is taking this stance. Am I missing something? >>>> >>>> -- Dick >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "OAuth" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to oauth+unsubscr...@googlegroups.com >>>> <mailto:oauth+unsubscr...@googlegroups.com>. >>>> For more options, visit https://groups.google.com/d/optout >>>> <https://groups.google.com/d/optout>. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "OAuth" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to oauth+unsubscr...@googlegroups.com >>> <mailto:oauth+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >>> >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "OAuth" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to oauth+unsubscr...@googlegroups.com >>> <mailto:oauth+unsubscr...@googlegroups.com>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OAuth" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to oauth+unsubscr...@googlegroups.com >> <mailto:oauth+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "OAuth" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to oauth+unsubscr...@googlegroups.com >> <mailto:oauth+unsubscr...@googlegroups.com>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to oauth+unsubscr...@googlegroups.com > <mailto:oauth+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to oauth+unsubscr...@googlegroups.com > <mailto:oauth+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to oauth+unsubscr...@googlegroups.com > <mailto:oauth+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to oauth+unsubscr...@googlegroups.com > <mailto:oauth+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "OAuth" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to oauth+unsubscr...@googlegroups.com > <mailto:oauth+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "OAuth" group. To unsubscribe from this group and stop receiving emails from it, send an email to oauth+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
