SAML login can require a retry

[gnprice]

This is a followup to #3670 where we implemented SAML auth. I just tried it out on the new beta 26.17.140, on @mateuszmandera's test server https://www.gentoox.net/ which uses Okta for auth. It worked, but there was a hiccup that'd be good to fix.

I'd seen similar symptoms in dev, but didn't find a reliable repro; and when I did get some debugging info, I could see it interacted with how the app had started up, and I wasn't sure whether it was affected by having reloaded JS in the debug build after starting up with a previous code version. Now it's been seen in a release build, so it's real -- though possibly annoying to repro and diagnose.

The sequence was:

• I launched the new version of the app.
• I went to "Switch account", and "Add new account".
• I entered www.gentoox.net, and after a couple of animations I got an Okta login page in a browser.
• I entered my username/email and password there.
• After a couple more animations, I landed back on the "Pick account" screen. This time there was an item for the gentoox.net account.
• I touched the button for that account, and after a few more animations I found myself properly logged in, at the normal unreads screen.

So in the end it worked fine, and I only had to enter my credentials once... but it didn't work the first time, and I had to hit a button to retry.

I didn't have a debugging console this time, naturally. But when I did use the debugging console (and add some console.log calls) when seeing something similar on a debug build, observations included:

• The getInitialURL() promise invoked in AuthScreen fired, with an initialUrl that was an actual URL of the expected form (rather than a value like null).
• That resulted in a call to endWebAuth, with authFromCallbackUrl returning a putative API key. But that key was pure garbage bytes -- presumably it was based on some otp value from some previous login attempt (possibly with some other auth method on a different server entirely?).
  • See the comment in webAuth.js for background. Our protocol for the Zulip server and a mobile client to complete a web-based login involves encrypting the API key with a one-time pad.
• So we thought we'd successfully logged in, but when we tried to fetch data the server promptly rejected our credentials, causing a LOGOUT action and dumping us back at the "Pick account" screen.

/cc @timabbott too

[gnprice]

Oh FWIW: this was on Android 10 on a Pixel 4.

[bmalynovytch]

Not sure if it's completely similar but I've got something not working properly as well.

In my case, I'm using a LemonLDAP-NG instance as SAML IdP, working fine with Zulip on browser (mobile & desktop), as well as desktop app, but not on mobile (iPhone).

I'm stuck on the IdP (post login) return page, with the integrated browser not closing. If I hit the "OK" button to close the "login browser", I'm back to the "choose auth method" and start again. Something strange, one of my colleagues had the exact same problem all day yesterday and finally manage to log in this morning.

On my side, I tried around 20 times with no luck.

[chrisbobbe]

Thanks for the report, @bmalynovytch! I'm not super familiar with the SAML flow specifically, but here are some debugging questions that might help:

Do I understand correctly:

You can make the browser go away by doing something boring, like closing it. I see a "Done" button:

If I press it, it brings me back to this page (yours will have different options):

And of course, instead of doing that, you'd like the browser to close automatically, logging you into the mobile app. You're not seeing either thing happening; after logging in in the browser, the browser just sits there without closing (at a post-login return page), and when you do close it manually (as above), you find that you haven't been logged into the mobile app.

---

I wonder if the server isn't serving the zulip:// redirect—or, if it is, I guess it could be doing so in a way the mobile app doesn't recognize or can't handle. But I believe the desktop app uses the same protocol, with the zulip:// redirect, and you've mentioned that it works on the desktop app. Hmm.

Your colleague's experience is also odd and interesting.

@mateuszmandera, do you think I might be right that the server might not be serving the zulip:// redirect?

[bmalynovytch]

I haven't checked regarding the zulip:// redirection, and I guess it is not sent, as we need to copy/paste a token to finish the signup process when connecting with the desktop app. I'll try to give it a look.

[bmalynovytch]

I can confirm that the POST to https://my-zulip.mydomain.com/complete/saml/ only returns 200 HTTP code with a token to copy paste in the desktop app.

[chrisbobbe]

Thanks, @bmalynovytch! Ah, also: I'd be interested to know what server version you're running, if you have that handy. For example, for https://chat.zulip.org (which we should probably move this conversation to if much more debugging is required 🙂), that can be found out with e.g.

curl -s https://chat.zulip.org/api/v1/server_settings | jq .zulip_version

(Or just visiting https://chat.zulip.org/api/v1/server_settings in a browser and searching for zulip_version there.)

I can confirm that the POST to https://my-zulip.mydomain.com/complete/saml/ only returns 200 HTTP code with a token to copy paste in the desktop app.

@mateuszmandera (or @andersk), am I right in thinking that it should serve the zulip:// redirect? But then also, it seems like the desktop app depends on the current behavior; hmm.

[chrisbobbe]

which we should probably move this conversation to if much more debugging is required 🙂

Great, I see you've posted at https://chat.zulip.org/#narrow/stream/48-mobile/topic/SAML.20Auth.20Loop/near/1154478; I'll see you there. 🙂

[bmalynovytch]

I finally traced down the issue: Safari gives an error when trying to call the zulip:// URL

Refused to load zulip://login?otp_encrypted_api_key=adbxxxxxxxxxxx71a0818b&email=xxxxxxxxx&realm=https%3A%2F%2Fzulip.xxxxxxxx because it does not appear in the form-action directive of the Content Security Policy.

[bmalynovytch]

If finally managed to authenticate, after lots of tests. Content-Security-Policy actionForm on IdP was set to as wildcard *. This doesn't seem to be enough for Chrome and Safari (the latter is used by the iOS app to authenticate). I had to change it to * https://*.mydomain.com zulip://* I guess the scheme needs to be added, wildcard isn't sufficient.