[Webkit-unassigned] [Bug 188165] iOS 12 Safari breaks ASP.NET Core 2.1 OIDC authentication

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=188165

--- Comment #3 from John Wilander <wilander at apple.com> ---
(In reply to David Cowden from comment #2)
> I'm chiming in to let people know this affects our own SSO infrastructure as
> well. We have an internal service that handles OIDC with an Okta instance
> (which, in turn, does upstream identity management--aka SAML--with the
> providers we support). The flow is essentially:
> 
> 1. our internal service sets a CSRF token on the first request and redirects
> us with an enriched URL containing OIDC arguments to our Okta instance, 
> 2. we OIDC->SAML bounce through Okta to the upstream IDP (a POST request is
> made during the SAML process), 
> 3. IDP authenticates user (possibly a second POST request is made if the
> user (re)authenticates upstream),
> 4. on the return trip when we are redirected to our internal service, we
> check the CSRF token set on the initial request, and handle the nonce
> provided by Okta,
> 5. ...internal service completes OIDC and redirects us to our desired final
> location...
> 
> The flow works on iOS < 12. On iOS 12 we don't see the CSRF token on the
> return trip, and step 4 fails. Interestingly, if the user actively refreshes
> the browser window, the cookie is sent which results in successful
> completion of the flow.
> 
> So this lead us to [RFC6265
> §5.3.7](https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-
> 5.3.7) which describes the mechanics of the `SameSite` cookie policy. Our
> CSRF cookie SameSite policy is set to `lax`. According to §5.3.7.1:
> 
> >  developers may set the "SameSite" attribute in a "Lax"
>    enforcement mode that carves out an exception which sends same-site
>    cookies along with cross-site requests if and only if they are top-
>    level navigations which use a "safe" (in the [RFC7231] sense) HTTP
>    method.
> 
> According to RFC7231, "safe" methods are only those methods which are
> idempotent. Specifically, a POST request is not "safe". Because our
> "top-level navigation" in the flow does not consist of strictly "safe"
> methods, WebKit is, as far as we understand, correctly interpreting
> RFC6265--which explains why the user-agent does not send our CSRF token and
> consequently step 4 fails. It also explains why refreshing the browser
> causes the cookie to be sent.
> 
> As stated, there is a discrepancy between previous WebKits and the version
> shipped with iOS 12. And indeed, other major non-webkit browsers claiming to
> support the `SameSite` attribute operate similar to the WebKit shipped with
> iOS < 12. However,  [RFC6265
> §8.8.3](https://tools.ietf.org/html/draft-ietf-httpbis-rfc6265bis-02#section-
> 8.8.3) states:
> 
> >  Likewise, some forms of Single-Sign-On might require cookie-based
>    authentication in a cross-site context; these mechanisms will not
>    function as intended with same-site cookies.
> 
> Removing the `SameSite` policy from our CSRF cookie resolves the issue and
> appears to be the intended solution. But, it feels weird that we're removing
> the `SameSite` policy from a cookie intended to defend against cross-site
> attacks...

It sounds like this should be resolved as Behaves Correctly then. And bugs should be opened for the other browsers.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180925/3d84c27a/attachment.html>