[Openid-specs-ab] ITP and OIDC session issues

Thu Jun 7 03:43:14 UTC 2018

On Wed, Jun 6, 2018 at 7:42 PM, David Waite via Openid-specs-ab <
openid-specs-ab at lists.openid.net> wrote:

> Just a FYI, SFAuthenticationSession is deprecated in iOS 12, for
> ASWebAuthenticationSession
> <https://developer.apple.com/documentation/authenticationservices/aswebauthenticationsession?language=objc>.
> As far as I can tell (without installing a beta on my phone) it is
> functionally equivalent, just externalized from the SafariServices package
> into the new AuthenticationServices package.
>

Yes, it looks like a simple rename/refactoring, the new class is
functionally identical. The deprecated one still works as well.

AppAuth for iOS has support for the new framework in the iOS 12 beta
<https://github.com/openid/AppAuth-iOS/tree/ios12beta> branch.

> It was talked about at https://developer.apple.
> com/videos/play/wwdc2018/204/ (28’36" in)
>
> -DW
>
> P.S. Is that four different mechanisms across 5 major versions? Good thing
> there are libraries to help with this.
>

Sure is
<https://github.com/openid/AppAuth-iOS/blob/8654472dbc346ebeed66bf295e8a0fdab9137ced/Source/iOS/OIDExternalUserAgentIOS.m#L93-L156>
!

On Jun 6, 2018, at 1:18 PM, Mike Jones <michael.jones at microsoft.com> wrote:
>
> For what it’s worth, the OpenID community successfully engaged with Apple
> last year to prevent them from breaking SSO when iOS 11 was released.
> Apple added the SFAuthenticationSession API in response to the feedback
> provided.  It’s probably possible for us to engage to prevent breakage
> again if there’s a clear problem definition and ask.
>
>                                                        -- Mike
>
> *From:* Openid-specs-ab <openid-specs-ab-bounces at lists.openid.net> *On
> Behalf Of *Vittorio Bertocci via Openid-specs-ab
> *Sent:* Wednesday, June 6, 2018 12:05 PM
> *To:* David Waite <david at alkaline-solutions.com>
> *Cc:* openid-specs-ab at lists.openid.net
> *Subject:* Re: [Openid-specs-ab] ITP and OIDC session issues
>
>
> Thanks David.
>
> Unfortunately server side session isn't an option for the JS SDK use case,
> where the app might not have a backend (and even if it does, enlisting it
> to acquire and renew tokens to be used by the JS frontend would entail
> adding legs to the protocol).
>
> About your conversation with Apple: would you be able to keep the list
> updated on what you learn from them? I would be happy to join the
> conversation and articulate the SDK use case, if that helps.
>
> Use of iFrames for renewing tokens has never been trouble free (the zones
> in IE Brock mentioned in a different branch, disabled 3rd party cookies
> etc) but this change would make the problem far more ubiquitous, to the
> point that standard workarounds (don;t disable 3rd party cookies; etc) will
> go from controversial to unfeasible.
>
> Thx
>
> V.
>
> On 6/6/18 10:58 AM, David Waite wrote:
>
> Hi Vittorio,
>
> Yes, Apple seems to be further moving from a model where all state is
> isolated not just on the origin of the content, but segmented on both the
> top-level URL bar location and the remote origin, e.g. a (local location,
> remote location) pair.
>
> They had this blog post about the change: https://webkit.org/
> blog/8311/intelligent-tracking-prevention-2-0/
>
> The option to prompt the user for storage access that apple has provided
> should only prompt once per site (hopefully), but can only be triggered
> once the user has interacted with that site, e.g. clicked on the iframe. So
> prompting is likely not only a bad UX from prompting, but would require the
> user to interact with a component that isn’t providing obvious value.
>
> The RFC is for the session access API that they have implemented above,
> prompting the user and requiring user interaction to use.
>
> Hopefully it is not too self-serving to note that the DTVA proposal uses
> back-end API to coordinate session management, so it should not be affected
> by this change.
>
>
> As a second point, I reached out to the web evangelist at Apple for
> clarification on how federated login sites can avoid being classified as
> tracking under ITP. In particular, it seems a fully transparent SSO
> (without user interaction with the IDP site) may cause the IDP to be
> classified, at which point future redirects for SSO will get a (RP, IDP)
> segmented state, with the user appearing unauthenticated and the browser
> looking like a unique browser.
>
> There are a lot of technical, security, and user knowledge/empowerment
> reasons to always have an IDP interaction on SSO, but it is a behavior that
> a lot of deployments strive very hard to avoid.
>
> -DW
>
>
> On Jun 6, 2018, at 9:53 AM, Vittorio Bertocci via Openid-specs-ab <
> openid-specs-ab at lists.openid.net> wrote:
>
> Hi all,
> We have been having issues with renewing tokens via invisible iFrame in
> our Javascript SDKs in the latest version of Safari - and yesterday's news
> about ITP 2.0 seem to suggest that the new default on Apple devices will be
> equivalent to disabling 3rd party cookies, which AFAIK breaks OIDC session
> management... and/or start displaying dialogs warning the user that they
> are being tracked at every operation.
> ·        Did anyone else experience similar issues?
> ·        What are the WG's thoughts about whether this calls for a
> revision of how session works in OIDC?
> ·        There is one RFC for WebKit that could provide an alternative
> location for the session, detailed here
> <https://github.com/whatwg/html/issues/3338>. Did anyone consider it? Any
> insights?
> If the issue is confirmed, that will make use of OIDC session and related
> token renewal machinery unfeasible on Macs, iPhones and iPads. And without
> official guidance, that will likely spur a cottage industry of custom
> solutions. I hope we can come up with guidance that addresses the problem
> before that happens.
> Thanks in advance for your insights
> V.
> _______________________________________________
> 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/20180606/1a339a2b/attachment.html>