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

Chuck Mortimore cmortimore at salesforce.com
Wed Jun 14 17:40:51 UTC 2017


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=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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170614/03a4ef59/attachment.html>


More information about the Openid-specs-ab mailing list