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

Iain McGinniss iainmcgin at google.com
Fri Jun 23 13:16:41 UTC 2017 

The full link if the short link isn't working:

https://docs.google.com/document/d/14m0P0I4GKW9awKvYtQ1Tv5rRsM95k8XaX0GlA9BrC3s/edit?usp=drivesdk

On Jun 23, 2017 07:44, "Steve Hutchinson" <sehutchinson at gmail.com> wrote:

> Iain,
>
> I tried to go to the link you included, which redirected to
> https://www.capsulink.com/GNmpPD which generates a "site cannot be
> reached" error.
>
> We have spent a great deal of time and effort educating and directing our
> developers to adopt AppAuth as our preferred model for native apps. I would
> be very interested in signing the document.
>
> Steve "Hutch" Hutchinson
>
>
>
> On Fri, Jun 23, 2017 at 6:04 AM, Iain McGinniss via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
>> http://cli.re/ios-11-sso is our community effort to do exactly this. If
>> you would be interested in signing the document, let me know. If we have
>> enough signatories by Monday we'll send it privately to Apple.
>>
>> On Jun 23, 2017 02:18, "Dominick Baier via Openid-specs-ab" <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>> Is there any chance you can convince Apple that the changes they make to
>> the Safari ViewController are actually bad for security?
>>
>>
>> -------
>> Dominick Baier
>>
>> On 20. June 2017 at 14:56:30, William Denniss via Openid-specs-ab (
>> openid-specs-ab at lists.openid.net) wrote:
>>
>> From a technical standpoint, I believe mobile Safari is currently the
>> best option for native app OAuth in iOS 11. Furthermore, due to UI
>> improvements to how iOS performs the app switch, it's a *lot* nicer than
>> when we last tried it in iOS 8 (where the context switch tended to feel a
>> bit jarring).
>>
>> The main issue in the past however was obtaining the policy permission
>> <http://openradar.appspot.com/radar?id=5744622710030336> to use mobile
>> Safari for sign-in. Your note is very intriguing Chuck.
>>
>> I'm thinking of adding mobile Safari as a supported option in AppAuth for
>> iOS, for those who have the ability to use it.
>>
>>
>> On Wed, Jun 14, 2017 at 1:55 PM, Chuck Mortimore via Openid-specs-ab <
>> openid-specs-ab at lists.openid.net> wrote:
>>
>>> We've managed to work through that with Apple, and have been using this
>>> technique on iOS for targeted use-cases for some time now.   Note that it
>>> is optional, and our default behavior is still in app.
>>>
>>> On Wed, Jun 14, 2017 at 11:09 AM, Iain McGinniss <iainmcgin at google.com>
>>> wrote:
>>>
>>>> On Wed, Jun 14, 2017 at 10:40 AM, Chuck Mortimore via Openid-specs-ab <
>>>> openid-specs-ab at lists.openid.net> wrote:
>>>>
>>>>> 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.
>>>>>
>>>>
>>>> Google Sign-in used to switch to Safari or an installed Google app to
>>>> perform authorization, and Apple stated that this was against their policy
>>>> and started rejecting apps from the app store that used this pattern.
>>>> SafariViewController is the only explicitly permitted mechanism for
>>>> federated identity on iOS.
>>>>
>>>> Iain
>>>>
>>>>
>>>>>
>>>>> 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+unsu
>>>>>>> bscribe 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
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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.net
>>> http://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
>>
>>
>> _______________________________________________
>> 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.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/20170623/293b2520/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4849 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170623/293b2520/attachment.p7s>

More information about the Openid-specs-ab mailing list