3 ms·

So what would be a good solution when you offer both email/password as well as multi tenant SSO as login methods? I want to cause as little friction, so that wo

by bouke 7y ago

So what would be a good solution when you offer both email/password as well as multi tenant SSO as login methods? I want to cause as little friction, so that would exclude a separate page/url for SSO logins. I could off course remember the user's email the first time, and offer SSO subsequent logins if cookies persisted. However, what to do about the first login? Most of the users will continue to use email/password, and I wouldn't want to show the password field to users that will be going to use SSO. So the password fields need to be conditional on the email (domain). I don't want to hardcode the SSO domains in the login form, so some roundtrip to the backend would be required. I see little option except for separating into two steps. A hidden password field would accommodate password managers and a cookie could remember which login flow was used previously and conditionally show the password field. What are your thoughts?

joshuak 7y ago
Create a bloom filter of your SSO domains. As the email field is populated check the domain against the bloom filter. If it matches disable the password field and display a message about that domain using sso and the user being redirected. In all other cases use normal password authentication. In the background use an ajax call to your server to validate the bloom filter. If you got a false positive then revert the UI to the password enabled version, but this will be extremely uncommon with the right size of bloom filter.
- hirsin 7y ago
  Are you suggesting that the bloom filter be pushed with the login page? That's like 10 MB of data on every login request. It's almost certainly faster to just do the Ajax call. (Assuming you have around 2 million domains supported - even at 200k that's over a megabyte).
  - CaptainMarvel 7y ago
    That doesn’t sound right. At 1MB for 200k domains is 5 characters per domain - the efficiency of that bloom filter is “almost” like sending the domains themselves. An online calculator suggested 230KB for a bloom filter of 200k items (1% error rate).
    - hirsin 7y ago
      Yeah, 1 percent is way too high is the concern. That will generate support calls and customer complaints. (plus, the same domains will always hit the problem, meaning those domains will specifically ask us to fix it - so... We send an extra list of known domains?)

by bouke 7y ago

joshuak 7y ago

Create a bloom filter of your SSO domains. As the email field is populated check the domain against the bloom filter. If it matches disable the password field and display a message about that domain using sso and the user being redirected. In all other cases use normal password authentication. In the background use an ajax call to your server to validate the bloom filter. If you got a false positive then revert the UI to the password enabled version, but this will be extremely uncommon with the right size of bloom filter.

hirsin 7y ago
Are you suggesting that the bloom filter be pushed with the login page? That's like 10 MB of data on every login request. It's almost certainly faster to just do the Ajax call. (Assuming you have around 2 million domains supported - even at 200k that's over a megabyte).
- CaptainMarvel 7y ago
  That doesn’t sound right. At 1MB for 200k domains is 5 characters per domain - the efficiency of that bloom filter is “almost” like sending the domains themselves. An online calculator suggested 230KB for a bloom filter of 200k items (1% error rate).
  - hirsin 7y ago
    Yeah, 1 percent is way too high is the concern. That will generate support calls and customer complaints. (plus, the same domains will always hit the problem, meaning those domains will specifically ask us to fix it - so... We send an extra list of known domains?)