[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

David Cowden <dcow at eero.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dcow at eero.com

--- Comment #2 from David Cowden <dcow at eero.com> ---
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...

-- 
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/67ee955d/attachment.html>