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

rich levinson rich.levinson at oracle.com
Wed Jun 14 15:52:19 UTC 2017

Hi Justin,

Based on your response, I am not sure whether it is addressing the actual suggestion
  that I made.

 1. The suggestion recommended that each app register w common redirect-uri "prefix".
      i.e. the suffix would likely include a unique identifier for the app within that prefix,
      so each app would have a "unique callback URI".
 2. The scheme is driven on the end-user side, by the end-user desiring to have SSO
      on the user's device. Therefore, when registering each app, which presumably is
      triggered by the end-user, who is loading the app on their device, all that needs
      to be done is have the device provide its proposed redirect-uri prefix to the app
      during registration, along w a flag indicating the intent is that this app is to be
      part of the SSO collection for the single-user device, plus the app, itself, providing
      the suffix that disambiguates it from other apps using the same prefix on the same
 3. The scheme is driven on the az-svr/OP side by the assignment of the unique client-id
      to the app, resulting in a unique redirect-uri + client-id pair for the registered app.
 4. Therefore, an intruder would need to know a.) the unique redirect-uri,
      b.) the unique client-id, and c.) the fact that the end-user has an active OP login state,
      in order to impersonate the app.
    The security of this combo would need to be compared to the security of a cookie,
      which is a bearer token, which could also be used by an intruder in the current
      scheme of things.

Bottom line, I think my suggestion might provide an easy-to-implement, easy-to-use,
and relatively equivalent level of security to the current schemes which are based
on cookies.

Also, a relatively small change to the az-svr impl could combine the "single-user device flag"
  w the registered redirect-uri to determine if an az-svr/OP session already exists for
  a client w the common redirect-uri prefix.

Note also, this suggestion is only intended to address the SSO issue, not the inter-app
  communication issue, which I think, in general, is separable and premature to discuss
  until a soln is found for SSO.

Also, Apple may be convinced to allow the cookies, in which case my suggestion is not needed,
  but could be considered as a fallback strategy for SSO if Apple does not allow the cookies.


On 6/14/2017 7:50 AM, Justin Richer wrote:
> This does not sound like a good idea and in fact goes against the advice in the native apps spec, which says that each app should have a unique callback URL.
> In order for this idea to work, you’d need to have everyone agree on a redirect URI generation scheme across all different apps, and have the AS recognize and process that scheme as well. This scheme could of course be easily coopted by attackers, but I don’t think that’s any different from the scheme registration we have today.
>  — Justin
>> On Jun 14, 2017, at 5:27 AM, rich levinson via Openid-specs-ab <openid-specs-ab at lists.openid.net <mailto:openid-specs-ab at lists.openid.net>> wrote:
>> Hi Iain, Justin, and Phil,
>> Thanks for the replies.
>> It seems that the issue boils down to the fact that under ordinary circumstances,
>> the user device would send the session cookie from the first login, which would
>> enable the OP to determine that the same user who is already logged in is making
>> a request from another app on the same device.
>> However, ios-11, w its app silo does not send this cookie, so the OP has no context,
>> for knowing the user is already logged in.
>> Based on looking @ the native app proposal:
>> https://tools.ietf.org/html/draft-ietf-oauth-native-apps-12
>> it appears possible that when a client app registers w the op, that the "redirect-uri"
>> could possibly designed such that all apps registered from a single device could
>> conceivably use a redirect-uri prefix that would identify those apps as sharing
>> a common device.
>> If the registration also included info that the common device was a "single-user device",
>> such as a cell phone, then when the client-app sends the authorization request,
>> the op could check if there was already a session set up for that device, inferring
>> that that a 2nd req from a 2nd app from the same single-user device could be associated
>> w the same user that had established a session from the 1st req from the 1st app of
>> the same "single-user device".
>> This would effectively be a scheme for replacing dependence on the cookie,
>>  w dependence on the integrity of the redirect-uri's registered w the op,
>>  which could also be double-checked w the client-id that the op assigned to the app.
>> Does that seem like a reasonable way to address the issue?
>>   Thanks,
>>   Rich
>> On 6/13/2017 5:57 PM, Iain McGinniss wrote:
>>> Each SFSafariViewController (SFSVC) instance is essentially a new browser, with the following consequences:
>>> 1. If the user signs in to the OP in Safari, this signed in state is not visible from any SFSVC instance.
>>> 2. If the user signs in via an SFSVC, this signed in state also cannot be synchronized to Safari.
>>> As a result, there's no shared OP session between any apps; the user must re-authenticate with the OP within every app that uses it.
>>> Furthermore, the Intelligent Tracking Prevention <https://urldefense.proofpoint.com/v2/url?u=https-3A__webkit.org_blog_7675_intelligent-2Dtracking-2Dprevention_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=kvp1Gz9oxuI7XBIptTmS8g-5lum7aIDRJPeRs9whB3c&s=SckFDrWm-pr4jO3aKXTNcLF9cFESHwKEi6xmYh4cbZs&e=> /may/ flag the OP domain as a capable of tracking the user, at which point any cookie / local storage state associated with that domain is "redacted" if the user has not interacted with the OP domain in the last 24 hours. "Interaction" here specifically means loading a top-level page on that domain and clicking on something. It seems highly likely that *.google.com 
>>> <https://urldefense.proofpoint.com/v2/url?u=http-3A__google.com_&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=kvp1Gz9oxuI7XBIptTmS8g-5lum7aIDRJPeRs9whB3c&s=fDWs3bFW2PpXshC3tcUA9HkqFp4Rpo6okQ8dZuJWQ9k&e=> is going to be marked as a tracking domain in Safari.
>>> So, if you do anything in iframes with your OP domains (we do at Google), your cookies are going to appear and disappear in a very unpredictable way. Session state is going to become very unreliable.
>>> I plan to give an impromptu short talk on these changes at CIS.
>>> Iain
>>> On Tue, Jun 13, 2017 at 2: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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__openid.net_specs_openid-2Dconnect-2Dsession-2D1-5F0.html&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=kvp1Gz9oxuI7XBIptTmS8g-5lum7aIDRJPeRs9whB3c&s=esCBAjLi0rE6cyxpEdt-kd2c61ezIJP_8v1euB48-kk&e=>
>>>      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 <https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openid.net_mailman_listinfo_openid-2Dspecs-2Dab&d=DwMFaQ&c=RoP1YumCXCgaWHvlZYR8PQcxBKCX5YTpkKY057SbK10&r=nNxUKneeZofWTyt9qclOUTeEg29NkEkknFyDupoNiiA&m=kvp1Gz9oxuI7XBIptTmS8g-5lum7aIDRJPeRs9whB3c&s=AdULqkg4OrLa18bnS9NfGgUMspZprPqSxSYwMR9bX04&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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20170614/af404876/attachment-0001.html>

More information about the Openid-specs-ab mailing list