SSO redirect loop with Lax cookies, but only for my IPhone?!

When I try to login on my IPhone (either Chrome or Safari), I end up with a redirect loop, bouncing away from / after being signed in even though it seems like discourse say I successfully sign in. I decided to try disabling the Lax cookie requirements and then things started to work. This issue only occur for my IPhone mobile, but not for any other mobile or computer. I’m using Discourse version v2.3.0.beta5 +169.

I have also tried disabling force-https, and then it still fails, only disabling Lax cookies seem to work, and using Strict cookies does not work either.

Any ideas or pointers on how I can find out what goes wrong for the IPhones? I’m using Okta -> Azure AD as a identity providers. I suspect Azure AD a bit for potentially doing something along the way, but I don’t know what it may be though.


Related

I’m using an IPhone with version 12.1.4.

Success vs Failure logs

Succeeding on my Computer (Ubuntu - Chrome)

  1. / — NOT LOGGED IN
  2. /session/sso
  3. my-sso
  4. /session/sso_login
  5. / — LOGGED IN
Started GET "/" for <redacted_ip> at 2019-03-26 07:18:23 +0000
Processing by CategoriesController#index as HTML
Redirected to https://discourse.example.com/session/sso
Filter chain halted as :redirect_to_login_if_required rendered or redirected
Completed 302 Found in 1ms (ActiveRecord: 0.0ms)

---

Started GET "/session/sso" for <redacted_ip> at 2019-03-26 07:18:23 +0000
Processing by SessionController#sso as HTML
Verbose SSO log: Started SSO process

nonce: 97aa661e9114d41814413a28359b9c77
return_sso_url: https://discourse.example.com/session/sso_login

Redirected to https://discourse-sso.example.com/sso/login?sso=redacted%3D%3D&sig=9586c5823337f624f987c1a2e8daa770cfcf960ca7f3ee845ed8d165db0b8c69
Completed 302 Found in 3ms (ActiveRecord: 0.0ms)

---

Started GET "/session/sso_login?sso=redacted&sig=9b66bc027724b460195cc6403a17f8cc7796551d69fcab8108ae123eef4a7157" for <redacted_ip> at 2019-03-26 07:18:55 +0000
Processing by SessionController#sso_login as HTML
  Parameters: {"sso"=>"redacted", "sig"=>"9b66bc027724b460195cc6403a17f8cc7796551d69fcab8108ae123eef4a7157"}
Verbose SSO log: User was logged on consideratio

admin: true
moderator: true
email: erik@redacted.com
external_id: 00u7sxngmxtnEfjQ8356
locale: en-US
name: Erik
nonce: 97aa661e9114d41814413a28359b9c77
return_sso_url: https://discourse.example.com/session/sso_login
username: erik@redacted.com

Redirected to https://discourse.example.com/
Completed 302 Found in 128ms (ActiveRecord: 48.2ms)

---

Started GET "/" for <redacted_ip> at 2019-03-26 07:18:55 +0000
Processing by CategoriesController#index as HTML
  Rendering categories/index.html.erb within layouts/application
# ...
# ...
# ...

Failing on my IPhone (Chrome, but I have also tried Safari)

  1. / — NOT LOGGED IN
  2. /session/sso
  3. my-sso
  4. /session/sso_login
  5. / — NOT LOGGED IN (and the sequence repeats itself)
Started GET "/" for <redacted_ip> at 2019-03-26 07:00:07 +0000
Processing by CategoriesController#index as HTML
Redirected to https://discourse.example.com/session/sso
Filter chain halted as :redirect_to_login_if_required rendered or redirected
Completed 302 Found in 2ms (ActiveRecord: 0.0ms)

---

Started GET "/session/sso" for <redacted_ip> at 2019-03-26 07:00:07 +0000
Processing by SessionController#sso as HTML
Verbose SSO log: Started SSO process

nonce: 76a497cbf008d9282f9adb0067b9c2d7
return_sso_url: https://discourse.example.com/session/sso_login

Redirected to https://discourse-sso.example.com/sso/login?sso=redacted%3D%3D&sig=3befcaa8c1b462dfe16cfe55761f09fdf9d83c7ef8be24689814cf4e84be43ef
Completed 302 Found in 5ms (ActiveRecord: 0.0ms)

---

Started GET "/session/sso_login?sso=redacted&sig=46f7360941e1f6861c904d4380919d90f2049fbb9c2eb0e916ac7ee341e0b5b4" for <redacted_ip> at 2019-03-26 07:00:53 +0000
Processing by SessionController#sso_login as HTML
  Parameters: {"sso"=>"redacted", "sig"=>"46f7360941e1f6861c904d4380919d90f2049fbb9c2eb0e916ac7ee341e0b5b4"}
Verbose SSO log: User was logged on consideratio

admin: true
moderator: true
email: erik@redacted.com
external_id: redacted
locale: en-US
name: Erik
nonce: 76a497cbf008d9282f9adb0067b9c2d7
return_sso_url: https://discourse.example.com/session/sso_login
username: erik@redacted.com

Redirected to https://discourse.example.com/
Completed 302 Found in 167ms (ActiveRecord: 67.6ms)

---

Started GET "/" for <redacted_ip> at 2019-03-26 07:00:53 +0000
Processing by CategoriesController#index as HTML
Redirected to https://discourse.example.com/session/sso
Filter chain halted as :redirect_to_login_if_required rendered or redirected
Completed 302 Found in 1ms (ActiveRecord: 0.0ms)
Started GET "/session/sso" for <redacted_ip> at 2019-03-26 07:00:53 +0000
Processing by SessionController#sso as HTML
Verbose SSO log: Started SSO process
# ...
# ...
# ...

As I recall there are bugs in Mobile Safari around this at the moment.

2 Likes

It reproduces on Chrome as well though, I’m suspecting IOS 12 on IPhone messing with the Lax cookies somehow.

3 Likes

Yes this is definitely the case, it is meant to be fixed in Safari 12.2 but iOS 12.2 ships Safari 12.1 :face_with_thermometer:

I would just switch of lax and strict cookies in your particular use case via site settings.

4 Likes

Chrome on iOS is literally that, window chrome around mobile Safari.

5 Likes

The specific bug is

Same-Site Lax cookies are not sent with cross-site redirect from a client-initiated load

In plain English, that means that things break when you enter your site url directly in the address bar, or when you click a link from another app. If you follow a link to your site within safari, it should work fine.

It was fixed in release 77 of the technology preview, but it doesn’t look like the fix made it into this week’s iOS 12.2 release :frowning:

7 Likes

Wow thank you all for helping pin this issue down, it makes my day :slight_smile: Will update this thread as soon as I know about resolutions to this.


@david oh crap… IOS Release 12.1 was September 2018, then half a year later now in March IOS Release 12.2 came with Safari 12.1 (source: wiki for release dates), but everything in between was security releases so I assume this may not be updated as it was included as a technology preview thing.

So I estimate half a year until IOS 12.3 comes with something newer than Safari 12.1 that will actually contain the fix in Safari technology preview 77.

Safari 12.1 is included with iOS 12.2 and macOS 10.14.4. It’s also available for macOS 10.13.6 and 10.12.6. — source


Risk of disabling my Lax cookies

If i disable Lax same site cookies, and one of my users is signed in, then visits another webpage with malicious javascript running on it. Is it correct that this malicious javascript could scrape my discourse, and perhaps also post comments as the user or do admin stuff if it was an admin user?

1 Like

Wieee! It was actually included in the IOS 12.2 update!!! :smiley: Because, it actually works now after upgrading to 12.2! :smiley:

Woooohoooooo!

4 Likes

That’s great! Maybe they fixed one part of the bug then :thinking: . I can certainly still reproduce the bug described above

(To reproduce, enter https://redirect-test.dtaylor.uk into your address bar, and you will get redirected to a version of Meta without any cookies)

2 Likes

Do you have an IOS 12.2 device? From my IPhone mobile with IOS 12.2, I arrived in a logged in state in the end, but i saw a flash of the login button first though and then it seemed tonreload and suddenly i was logged in. So, then I assume I passed cookies? Or, did i not pass cookies but triggered a redirect back and then cookies were provided on the second redirect back for as i now came from the same domain? Hmmm… Eh…

How do you notice from you IOS device if cookies were sent? By being logged in at some point? Then i failed to reproduce on my IOS 12.2 IPhone when using https://redirect-test.dtaylor.uk/ from a new tab.

More exactly, what i did was:

  1. Visit meta.discourse.org in an incognito window and sign in with github
  2. Visit google.com
  3. Pasted https://redirect-test.dtaylor.uk/ into my address bar
  4. (without action, only observation) Saw the login button, page seemed to refresh, i was logged in.

Oh!!! BUT! But i could reproduce it by testing meta.discourse.com!!! Then im not logged in when redirected to meta.discourse.org but accessing meta.discourse.org directly makes it fine.

Hmmm, perhaps https://redirect-test.dtaylor.uk/ is redirecting to http and then im force redirected from http to https within the meta.discourse.org domain and then i arrive corectly with cookies provided on the second arrival?

3 Likes