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

Fri Jun 23 11:04:11 UTC 2017

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+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
>>>>
>>>>
>>>
>>> _______________________________________________
>>> 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/1ecaa6ef/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/1ecaa6ef/attachment.p7s>