[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.html>
More information about the Openid-specs-ab
mailing list