Apple announced new changes in iOS 9 this morning. Not all changes got a mention on stage. This one caught my eye as being relevant to this thread:
SFSafariViewController can be used to display web content within your app. > It shares cookies and other website data with Safari, and has many of > Safari's great features, such as Safari AutoFill and Safari Reader. Unlike > Safari itself, the SFSafariViewController UI is tailored for displaying a > single page, featuring a Done button that takes users back to where they > were in your app. (source > <https://developer.apple.com/library/prerelease/ios/releasenotes/General/WhatsNewIniOS/Articles/iOS9.html#//apple_ref/doc/uid/TP40016198-DontLinkElementID_26> > ) > I am curious to see what this actually looks like in iOS, but I'm guessing it will show the address bar or have some other indication of the site the user is actually on. This could be used for an embedded OAuth flow while still being secure, and has the benefit of using the system cookies so that users might already be signed in. On Tue, May 12, 2015 at 7:14 AM, nov matake <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> > 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 <[email protected]> >> 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 <[email protected]> >>> 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://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 >>>> >>>> >>>> On Mon, May 11, 2015 at 10:12 PM, Joost van Dijk < >>>> [email protected]> 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 <[email protected]> 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 <[email protected]> >>>>> 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 <[email protected]> のメッセージ: >>>>>> >>>>>> 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 < >>>>>> [email protected]> 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 <[email protected]> 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 [email protected]. >>>>>>> For more options, visit 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 [email protected]. >>>>>>> For more options, visit 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 [email protected]. >>>>>> For more options, visit 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 [email protected]. >>>>>> For more options, visit 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 [email protected]. >>>>> For more options, visit 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 [email protected]. >>>>> For more options, visit 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 [email protected]. >>>> For more options, visit 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 [email protected]. >>> For more options, visit 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 [email protected]. >> For more options, visit 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 [email protected]. > For more options, visit 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 [email protected]. > For more options, visit 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
