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

Mon Jun 19 04:54:29 UTC 2017

Maybe we should revive the Napps WG. 

--
PLEASE READ This e-mail is confidential and intended for the named recipient only. If you are not an intended recipient, please notify the sender and delete this e-mail. 

----Original Message----
From: Chuck Mortimore via Openid-specs-ab <openid-specs-ab at lists.openid.net>
To: George Fletcher <gffletch at aol.com>
CC: openid-specs-ab at lists.openid.net Ab <openid-specs-ab at lists.openid.net>
Date: Sat Jun 17 06:28:55 JST 2017
Sub: Re: [Openid-specs-ab] Single Sign-On is dead on iOS 11

> Yes...yes it does :)
> 
> - cmort
> 
> On Jun 16, 2017, at 1:59 PM, George Fletcher <gffletch at aol.com> wrote:
> 
> Sounds a bit like the original "Native Apps" OIDF working group flow:)
> 
> On 6/14/17 3:01 PM, Chuck Mortimore wrote:
> 
> Hi Chris
> 
> In current state, we have an option to switch to mobile safari on a
> per-customer basis.  When our apps boot, if configured with a tenant
> specific URL, they load metadata from a .well-known endpoint which controls
> this behavior.   PKCE is used to secure callbacks over custom scheme URIs.
> 
> We're currently working on adding the ability to specify a custom scheme to
> act as the IDP, as well as specific software in our mobile SDKs to deal
> with the handleOpenURL calls.   Essentially an SP app reads metadata,
> switches to IDP app, which uses it's session to initiate the OAuth flow for
> the SP app.  Once approved a custom scheme redirect_uri switches back to
> the SP app which completes the OAuth flow (PKCE verified)
> 
> 
> 
> 
> On Wed, Jun 14, 2017 at 11:10 AM, Chris Phillips <Chris.Phillips at canarie.ca>
> wrote:
> 
> > 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=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/mailma
> >> n/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/mailma
> >> n/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