omniauth-oauth2 icon indicating copy to clipboard operation
omniauth-oauth2 copied to clipboard

Default Safari 8.0+ settings ignore cookies on redirect which breaks CSRF validation

Open mcolyer opened this issue 10 years ago • 7 comments

After several hours of investigation it looks like Safari's implementation of "Allow from current websites only" cookie blocking changed. I can't find any official description but as far as I can tell Set-Cookie headers on redirects to sites on different hosts are ignored (which is exactly what happens when navigating to an oauth authorization url).

It's unclear to me how to workaround this other than using an ActiveRecord backed session table (which is definitely less than ideal) or by asking users to change their settings.

mcolyer avatar Mar 31 '15 00:03 mcolyer

Some possible workarounds are listed in https://github.com/zotonic/zotonic/issues/902#issuecomment-77099448.

mcolyer avatar Mar 31 '15 00:03 mcolyer

Upon further investigation it appears that Safari isn't passing any cookies on the redirect from the provider to the callback url when "Allow from current websites only" is set. Unfortunately to workaround that issue changes would need to be implemented on the provider side (which doesn't involve omniauth-oauth2)

However if the cookies are also not being set on the redirect to the provider (which is hard to determine due to the above issue) changes would need to be made to omniauth-oauth2.

mcolyer avatar Mar 31 '15 15:03 mcolyer

@mcolyer Hey ventured over here from Google searching around. Did you ever figure out a permanent solution for handling Safari 8 users with login issues?

I'm dying to figure out a solution for this since I'm receiving frequent emails about broken logins for Safari users for one of my free sites myfav.es

jlukic avatar May 02 '15 01:05 jlukic

So it turns out that this issue has to be worked around by the OAuth provider that you are using as they are the ones setting the cookies which are being ignored. Several OAuth providers have workarounds (Facebook, Google) while others do not (Mailchimp).

So long story short, there's not much you can do to fix the situation other than ask providers nicely.

mcolyer avatar May 02 '15 12:05 mcolyer

Several OAuth providers have workarounds (Facebook, Google) while others do not (Mailchimp)

We're experiencing a similar sounding issue with Safari 8.0.5 and omniauth-oauth2 1.3.1. With "Allow from current websites only", oauth from Google and Facebook fails due to the session not holding the state, and with "Allow from websites I visit" the oauth request works as expected.

I'm interested to hear that Google and Facebook are working for you. Did you have to do anything special to get them working?

Our omniauth config looks like this:

Rails.application.config.middleware.use OmniAuth::Builder do
  provider :twitter, "XXX", "XXX"
  provider :facebook, "XXX", "XXX"
  provider :google_oauth2, "XXX", "XXX", {
    name: 'google',
    scope: 'userinfo.email, userinfo.profile',
    prompt: 'select_account',
  }
end

yob avatar Jul 08 '15 12:07 yob

I'm interested to hear that Google and Facebook are working for you. Did you have to do anything special to get them working?

I didn't specifically test it with omniauth but I was able to OAuth to other sites using Safari with "Allow from current websites only" enabled on those providers. There might be other changes required as I noted earlier:

However if the cookies are also not being set on the redirect to the provider (which is hard to determine due to the above issue) changes would need to be made to omniauth-oauth2.

I'd be interested to hear if there were. Can you dump out the cookies on the request/responses you are seeing?

mcolyer avatar Jul 19 '15 15:07 mcolyer

I opened a radar about this a while back. And, it sounds like it is a bug that is supposedly fixed in the public beta of the next OS release: https://bugs.webkit.org/show_bug.cgi?id=139683.

ptoomey3 avatar Sep 01 '15 22:09 ptoomey3