This is the best news I've heard all year (if it does work well for OAuth).
On Mon, Jun 8, 2015 at 3:16 PM, Aaron Parecki <[email protected]> wrote: > 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. > -- 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.
