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> 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.
For more options, visit https://groups.google.com/d/optout.

Reply via email to