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

George Fletcher gffletch at aol.com
Fri Jun 16 21:01:14 UTC 2017

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 <mailto: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
>     <https://technical.edugain.org/status>
>     From: Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net
>     <mailto:openid-specs-ab-bounces at lists.openid.net>> on behalf of
>     Chuck Mortimore via Openid-specs-ab
>     <openid-specs-ab at lists.openid.net
>     <mailto:openid-specs-ab at lists.openid.net>>
>     Reply-To: Chuck Mortimore <cmortimore at salesforce.com
>     <mailto:cmortimore at salesforce.com>>
>     Date: Wednesday, June 14, 2017 at 1:40 PM
>     To: George Fletcher <gffletch at aol.com <mailto:gffletch at aol.com>>
>     Cc: "openid-specs-ab at lists.openid.net
>     <mailto:openid-specs-ab at lists.openid.net> Ab"
>     <openid-specs-ab at lists.openid.net
>     <mailto: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
>     <mailto: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
>>>         <mailto: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
>>>         <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
>>>>         <mailto: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
>>>>             <mailto: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 list
>>>>         Openid-specs-ab at lists.openid.net
>>>>         <mailto:Openid-specs-ab at lists.openid.net>https://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=
>>>>         <https://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
>>>         <mailto:Openid-specs-ab at lists.openid.net>
>>>         http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>         <http://lists.openid.net/mailman/listinfo/openid-specs-ab> 
>>         _______________________________________________
>>         Openid-specs-ab mailing list
>>         Openid-specs-ab at lists.openid.net
>>         <mailto:Openid-specs-ab at lists.openid.net>http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>         <http://lists.openid.net/mailman/listinfo/openid-specs-ab>
>         _______________________________________________
>         Openid-specs-ab mailing list Openid-specs-ab at lists.openid.net
>         <mailto:Openid-specs-ab at lists.openid.net>
>         http://lists.openid.net/mailman/listinfo/openid-specs-ab
>         <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/20170616/69ded9b2/attachment-0001.html>

More information about the Openid-specs-ab mailing list