[Openid-specs-ab] Single Sign-On is dead on iOS 11

Fri Jun 23 07:18:26 UTC 2017

Is there any chance you can convince Apple that the changes they make to
the Safari ViewController are actually bad for security?

-------
Dominick Baier

On 20. June 2017 at 14:56:30, William Denniss via Openid-specs-ab (
openid-specs-ab at lists.openid.net) wrote:

>From a technical standpoint, I believe mobile Safari is currently the best
option for native app OAuth in iOS 11. Furthermore, due to UI improvements
to how iOS performs the app switch, it's a *lot* nicer than when we last
tried it in iOS 8 (where the context switch tended to feel a bit jarring).

The main issue in the past however was obtaining the policy permission
<http://openradar.appspot.com/radar?id=5744622710030336> to use mobile
Safari for sign-in. Your note is very intriguing Chuck.

I'm thinking of adding mobile Safari as a supported option in AppAuth for
iOS, for those who have the ability to use it.

On Wed, Jun 14, 2017 at 1:55 PM, Chuck Mortimore via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> We've managed to work through that with Apple, and have been using this
> technique on iOS for targeted use-cases for some time now.   Note that it
> is optional, and our default behavior is still in app.
>
> On Wed, Jun 14, 2017 at 11:09 AM, Iain McGinniss <iainmcgin at google.com>
> wrote:
>
>> On Wed, Jun 14, 2017 at 10:40 AM, Chuck Mortimore via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>>> We're proceeding with an implementation that allows us to target mobile
>>> safari or a registered mobile app as the IDP.  Perhaps a little closer to
>>> earlier drafts.  Happy to share our plans if anyone is interested.
>>>
>>
>> Google Sign-in used to switch to Safari or an installed Google app to
>> perform authorization, and Apple stated that this was against their policy
>> and started rejecting apps from the app store that used this pattern.
>> SafariViewController is the only explicitly permitted mechanism for
>> federated identity on iOS.
>>
>> Iain
>>
>>
>>>
>>> On Wed, Jun 14, 2017 at 8:09 AM, George Fletcher via Openid-specs-ab <
>>> openid-specs-ab at lists.openid.net> wrote:
>>>
>>>> However, if the user is using iCloud keychain, then their credentials
>>>> should be filled in for the user so not too bad. The issue, is that if
>>>> account is using 2FA the user will have to do the 2FA dance for every app.
>>>> That could be a pain.
>>>>
>>>> Thanks,
>>>> George
>>>>
>>>> On 6/13/17 5:57 PM, Justin Richer via Openid-specs-ab wrote:
>>>>
>>>> This has nothing to do with OIDC’s session management, but rather
>>>> sessions in the browser itself. From what I understand, the per-app silos
>>>> would prevent the OP from knowing it’s the same user coming in from
>>>> different apps, since they wouldn’t have access to the session and cookie
>>>> jar. So the UX degrades rather poorly as the user is prompted to log in
>>>> separately to their identity provider (with primary credentials) from every
>>>> single app.
>>>>
>>>>  — Justin
>>>>
>>>> On Jun 13, 2017, at 5:40 PM, rich levinson via Openid-specs-ab <
>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>
>>>> Hi Nat, et al,
>>>>
>>>> I am not sure I understand why this situation should cause anything to
>>>> "break".
>>>>
>>>> Let me explain my view of this situation, in the context of general
>>>> session mgmt,
>>>> which is the following:
>>>>
>>>> In the "OpenID Connect Session Management 1.0" spec:
>>>>     http://openid.net/specs/openid-connect-session-1_0.html
>>>>  it says:
>>>>
>>>> "In OpenID Connect, the session at the RP typically starts
>>>>  when the RP validates the End-User's ID Token.
>>>>   ...
>>>> When the OP supports session management, it MUST also return the Session State
>>>>  as an additional session_state parameter in the Authentication Response.
>>>>   ...
>>>> This parameter is:
>>>>     session_state
>>>>      Session State.
>>>>      JSON [RFC7159] string that represents the End-User's login state at the OP.
>>>>      It MUST NOT contain the space (" ") character.
>>>>      This value is opaque to the RP.
>>>>      This is REQUIRED if session management is supported.
>>>>
>>>> The Session State value is initially calculated on the server."
>>>>
>>>> This indicates that the OP has knowledge of the End-User's login state
>>>> at the OP.
>>>> However, this login state is independent of the "session at the RP",
>>>> which is
>>>> created when the client app (RP) rcv's the identity token which, in the
>>>> protocol,
>>>> is well after the End-User logged in at the OP.
>>>>
>>>> Later in the spec, section 5, it is also stated that:
>>>>
>>>> "5.  RP-Initiated Logout
>>>> An RP can notify the OP that the End-User has logged out of the site and
>>>>  might want to log out of the OP as well.
>>>> In this case, the RP, after having logged the End-User out of the RP,
>>>>  redirects the End-User's User Agent to the OP's logout endpoint URL.
>>>> This URL is normally obtained via the end_session_endpoint element
>>>>  of the OP's Discovery response or may be learned via other mechanisms."
>>>>
>>>> This basically confirms the supposition above that the OP login and the
>>>> RP session are
>>>> effectively independent entities.
>>>>
>>>> Now, let's consider the case where a 2nd RP decides to start a session
>>>> w the same End-User,
>>>> presumably, a 2nd RP on the same device where the 1st RP established a
>>>> session.
>>>>
>>>> When the 2nd RP sends the Authentication Request to the OP's /authorize
>>>> endpoint,
>>>> it seems obvious to me that the OP knows the End-User is logged in and
>>>> would have
>>>> no problem issuing a 2nd id-token to the 2nd RP, w/o re-logging in the
>>>> End-User.
>>>>
>>>> Assuming this is the case, then I do not understand why ios-11, by
>>>> "siloing" the apps
>>>> prevents the OP from issuing new id-tokens to each app, all under the
>>>> original
>>>> OP-login by the End-User.
>>>>
>>>> Am I missing something?
>>>>
>>>>   Thanks,
>>>>   Rich
>>>>
>>>>
>>>>
>>>>
>>>> On 6/12/2017 8:04 PM, Nat Sakimura via Openid-specs-ab wrote:
>>>>
>>>> Maybe we can call upon the privacy community as well raising the voice
>>>> that this is very bad for privacy.
>>>> I wonder what is the privacy enhancement they have in mind.
>>>>
>>>> On Fri, Jun 9, 2017 at 2:34 AM 'Iain McGinniss' via OIDF Account
>>>> Chooser list <oidf-account-chooser-list at googlegroups.com> wrote:
>>>>
>>>>> Hello all,
>>>>>
>>>>> Just to bring this to your attention: Apple has essentially killed
>>>>> single sign-on for native apps in iOS 11. Changes made to
>>>>> SFSafariViewController (used by AppAuth, and the recommended mechanism for
>>>>> federated login by Apple) now mean that browser state is partitioned per
>>>>> app, so there is no way for an existing authentication in the browser to be
>>>>> reused by an app.
>>>>>
>>>>> This fundamentally breaks an important part of OpenID Connect - users
>>>>> will now need to re-authenticate with their IDP in every app that they use.
>>>>> There is still time to provide feedback to Apple on this change, though
>>>>> they have been discussing this change in terms of "enhancing privacy" and
>>>>> I'd be very surprised if they change tack now.
>>>>>
>>>>> Iain
>>>>> --
>>>>>
>>>>> ---
>>>>> You received this message because you are subscribed to the Google
>>>>> Groups "OIDF Account Chooser list" group.
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to oidf-account-chooser-list+unsubscribe at googlegroups.com.
>>>>> For more options, visit https://groups.google.com/d/optout
>>>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__groups.google.com_d_optout&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=z6H6MqLIToKnju5TQdKnYOa6pGD9lyMxhwLO-mdMgac&s=XtvXRyjw8QvajPlQD8M0d6xQJnp_3jK9zv_hDOXEOXY&e=>
>>>>> .
>>>>>
>>>> --
>>>>
>>>> Nat Sakimura
>>>>
>>>> Chairman of the Board, OpenID Foundation
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttps://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwICAg&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=z6H6MqLIToKnju5TQdKnYOa6pGD9lyMxhwLO-mdMgac&s=tYftjD7QNKeiH9oZIyspoUu_QX44iHnFoAzyiuQapmg&e=
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing listOpenid-specs-ab at lists.openid.nethttp://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-specs-ab at lists.openid.net
>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> Openid-specs-ab at lists.openid.net
>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>
>>>
>>
>
> _______________________________________________
> Openid-specs-ab mailing list
> Openid-specs-ab at lists.openid.net
> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>
>
_______________________________________________
Openid-specs-ab mailing list
Openid-specs-ab at lists.openid.net
http://lists.openid.net/mailman/listinfo/openid-specs-ab
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170623/49bc1301/attachment.html>