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

Wed Jun 14 18:10:00 UTC 2017

Hi Chuck,
Yes, please share. Definitely interested in understanding the approach
particularly the scaling aspects of the technique.
As an operator of a national federation that participates worldwide with
thousands of IdPs[1]  it's helpful to understand how portable the approach
is.

Thanks!
C

[1]  https://technical.edugain.org/status

From:  Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> on behalf
of Chuck Mortimore via Openid-specs-ab <openid-specs-ab at lists.openid.net>
Reply-To:  Chuck Mortimore <cmortimore at salesforce.com>
Date:  Wednesday, June 14, 2017 at 1:40 PM
To:  George Fletcher <gffletch at aol.com>
Cc:  "openid-specs-ab at lists.openid.net Ab"
<openid-specs-ab at lists.openid.net>
Subject:  Re: [Openid-specs-ab] Single Sign-On is dead on iOS 11

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.

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=nNxUKneeZo
>>>>> fWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=z6H6MqLIToKnju5TQdKnYOa6pGD9lyMxhwLO-m
>>>>> dMgac&s=XtvXRyjw8QvajPlQD8M0d6xQJnp_3jK9zv_hDOXEOXY&e=> .
>>>> -- 
>>>> Nat Sakimura
>>>> 
>>>> Chairman of the Board, OpenID Foundation
>>>> 
>>>>  
>>>> _______________________________________________
>>>> Openid-specs-ab mailing list
>>>> Openid-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=R
>>>> oP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkE
>>>> kknFyDupoNiiA&m=z6H6MqLIToKnju5TQdKnYOa6pGD9lyMxhwLO-mdMgac&s=tYftjD7QNKeiH
>>>> 9oZIyspoUu_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.nethttp://lists.openid.net/mailman/listinfo/open
>> id-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/20170614/9d2185df/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5451 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170614/9d2185df/attachment.p7s>