OAuth authentication broken due to SameSite cookie policy #1231
Description
The SameSite=strict
cookie default added in #908 breaks OAuth handlers setting Cookies on signin because the user action was taken on a different origin.
The problem only when the user actually has to log in or otherwise interact with their OAuth provider. In that case, user action is initiated in the domain of the OAuth provider, so when the browser redirects back to the relying party, which then sets a SameSite=strict
cookie, the browser refuses to send it on the next request. The flow is something like this (for app at http://app
and provider at http://provider
:
- Browser sends
GET http://app
302
redirect tohttp://provider
- Browser sends
GET http://provider
200
response with login page- User completes login
- Browser sends
POST http://provider
302
redirect tohttp://app/signin-oauth?code=...&state=...
- Browser sends
GET http://app/signin-oauth?code=...&state=...
302
redirect tohttp://app
withSet-Cookie
header withsamesite=strict
- Browser sends
GET http://app
however since the last document rendered to the user had an origin ofprovider
, it refuses to send the cookie set by step 9.
This leads to a cycle in most ASP.NET OAuth configurations because it keeps trying to authenticate via a series of 302
s (because the provider a) already has a login cookie and b) is the origin site, so it keeps getting it's login cookie).
This should repro trivially by running any of the social login samples in an incognito window (forcing you to login).
Assuming I'm not missing something simple, all OAuth-based authentication providers are broken by this new default. We need to make some kind of fix/change in preview 2.