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

Wed Aug 23 07:31:53 UTC 2017

Hi,

FYI:
I've confirmed iOS11's Intelligent Tracking Prevention treated IdP domain
as "having tracking capability" and didn't send IdP cookie in iframe after
24h.
So that prompt=none w/ hidden iframe only works within 24 hours since last
login action at IdP.

I'm still not unsure about the local storage behaviour though.

2017-06-14 6:57 GMT+09:00 Iain McGinniss via Openid-specs-ab <
openid-specs-ab at lists.openid.net>:

> Each SFSafariViewController (SFSVC) instance is essentially a new browser,
> with the following consequences:
>
> 1. If the user signs in to the OP in Safari, this signed in state is not
> visible from any SFSVC instance.
> 2. If the user signs in via an SFSVC, this signed in state also cannot be
> synchronized to Safari.
>
> As a result, there's no shared OP session between any apps; the user must
> re-authenticate with the OP within every app that uses it.
>
> Furthermore, the Intelligent Tracking Prevention
> <https://webkit.org/blog/7675/intelligent-tracking-prevention/> *may* flag
> the OP domain as a capable of tracking the user, at which point any cookie
> / local storage state associated with that domain is "redacted" if the user
> has not interacted with the OP domain in the last 24 hours. "Interaction"
> here specifically means loading a top-level page on that domain and
> clicking on something. It seems highly likely that *.google.com is going
> to be marked as a tracking domain in Safari.
>
> So, if you do anything in iframes with your OP domains (we do at Google),
> your cookies are going to appear and disappear in a very unpredictable way.
> Session state is going to become very unreliable.
>
> I plan to give an impromptu short talk on these changes at CIS.
>
> Iain
>
> On Tue, Jun 13, 2017 at 2: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 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/20170823/f42e567f/attachment.html>