Why Single Sign on Sucks

GitHub&#x27;s SSO if it&#x27;s not Enterprise managed accounts sucks. Thus the example is extremely unlucky.<p>Industry standard is that service provider gets identity from identity provider and provisions an account with that identity. So that if I log in to Jira as john.smith@example.com I&#x27;ll have john.smith@example.com username.<p>What GitHub does is it links enterprise identity to personal account. So I have to log in twice (and honestly it&#x27;s already not an SSO at this stage) first time I log in with enterprise identity and then I log in with personal account. So I log in as john.smith@example.com, then login as HugeDick53 and then I&#x27;m visible as HugeDick53 and john.smith@example.com identity vanishes from view.<p>GitHub&#x27;s justification is that contributions on enterprise projects should be visible on personal accounts. However, from administrator&#x27;s point of view entire system + UI issues make this type of so called SSO completely unusable. Nobody in company has any idea who is HugeDick53.<p>On the other hand Atlassian products provide true SSO. Not the most sophisticated one, but at least it&#x27;s SSO.

My experience is completely opposite of the author&#x27;s. I sign on once a day when I access a service that uses my firm&#x27;s SSO solution. I&#x27;m then automatically signed in to all other services as I use them. It&#x27;s quite seamless. I have no complaints about the SSO setup in my firm.

I feel like this article misses the point that SSO is intended to benefit organisations, not users. The selling point is that if an IT department can point a new service at Active Directory or something, it&#x27;s going to be much less of a headache than managing n sets of user credentials.

The author&#x27;s complaint is really against authentication in general rather than SSO. Different sites and services have always and will always use their own authn&#x2F;authz methods, simply because it isn&#x27;t a generic problem that can be abstracted away. You can outsource parts of it (show the user a username&#x2F;password form, validate credentials, verify email, check 2FA) which is what all these SSO providers aim to do.<p>Also the examples they mention are all just badly configured applications, which can easily be fixed.

Maybe someone can answer this, why are client certificates not more popular instead of something like VPN for work? I suppose even with client cert, you would still need to login, though if your computers login is already managed through AD&#x2F;ldap or something and you enforce timeout logout policies you could argue that if you are logged into your machine that is good enough. Even if not, then a client cert plus a SSO token&#x2F;session cookie should be good enough right?

This is the problem Kerberos solved. It solved it well.<p>You log on to your workstation, do whatever auth dance, and then that ticket gets used by SSH, your web browser and everything else to seamlessly log you into other services.<p>When it works, it works really well, but absolutely no one implements support for it.

Weird timing. I was just dealing with an issue related to this.<p>I had a work a phone. I restored an image to my personal iPhone and just today tried to sign on to Youtube. It redirected me to the SSO page for my former employer&#x27;s page. Why? I guessed I&#x27;d signed on to my corp Google account on my phone at some point and it remembered. Googling didn&#x27;t find an easy answer. There was no opt out button (on the login screen or on YT) and no clear way to bypass it. After some googling I ended up just deleting every Google related cookie on my phone and that seemed to clear it up.<p>This is a terrible user experience.<p>But even when you are signed in to more than one account it&#x27;s terrible. You get a link to a Google doc, click on it and it says &quot;you don&#x27;t have permission&quot;. More often than not Google has decided to try as your personal Google account not your corp account. But I bet there is a ton of confused people who click &quot;Request Access&quot; and are confused why it doesn&#x27;t work.<p>I haven&#x27;t experienced the author&#x27;s issue of 43 sign-ons a day. Sounds like a bad enterprise setup.<p>I&#x27;m not sure what the solution to this is but my first thought is resource ownership should be clear from the URL eg it should use a domain name other than google.com. There are probably problems with that. Whatever the case, currently it&#x27;s terrible.<p>More often than not I find myself segragating Google accounts by browser (or browser profile). That&#x27;s a pretty clear sign the product experience, well, sucks.

not a great article. apart from multiple wrong or missing words, the section about browser profiles is just plain weird and ignoring firefox premiered this without any tracking motivation and also with different set of problems in mind. many sections read as if the author did slightly superficial or slightly off research.

This is how I login to SSO today at work: Login username is cached in browser. Password is auto-filled-in by my password manager, which is in turn unlocked for a period of time when I am logged into my desktop. I hit &quot;Log In&quot; button. Backend does magic. An app pops up on my phone. I supply my fingerprint. Authentication is approved, and my browser is now logged in.<p>Same pattern works for logging into AWS from the console. My password manager keeps the username and password. Every time my AWS temporary session token expires, AWS CLI asks saml2aws for a new session token. Saml2aws gets user&#x2F;password from the password manager, logs in. If session has expired, I get a pop-up on my phone asking me to log in. I supply fingerprint. Authentication is approved, and saml2aws creates a new session, passes it to AWS CLI, and I&#x27;m off to the races.<p>I can control exactly how often I have to enter in a password (to unlock my password manager), and the site administrator determines how long my sessions last. Is it <i>super duper secure</i>? No. But is it better than me typing my password, hitting submit, getting a text message, and typing a code in? Absolutely.<p>The same pattern can totally work across multiple sites. The standards just need to be changed to allow it to happen. This isn&#x27;t a technical problem, it&#x27;s a political one.

SSO sucks nothing in compare with TOTP-incompatible &quot;please scan QR&quot; mobile auth. With uniq app per service.

I thought my signin woes were finally solved after moving everything over to 1Password. It works great and auto-fills usernames&#x2F;passwords and TOTPs with a shortcut.<p>But Github recently rolled out a default 2FA that uses their app on my phone instead of the 2FA code. Luckily they support switching back to TOTPs for now. But now that passwordless is the new sign-in meme, i can look forward to having to migrate everything all over again to a different broken solution like client certificates or biometric auth again in a few years.<p>In 5 years, someones OS is compromised and their client certificates are hacked. Or some kind of centralized storage for client certificates is hacked, or a certificate authority is hacked. Industry will then decide &quot;omg client certificates are insecure&quot; and we can migrate to some other crap again.<p>Or we can all move to SSO. Even if we had perfect once a day SSO, what if an employee leaves their laptop unattended? One day that will happen, some company will get hacked, and then &quot;once a day SSO is insecure&quot;..

&gt; While it’s possible to create cookie with credentials, this should be avoided due to all the possibilities of CSRF Attacks<p>This is no longer an issue, if you use SameSite=Strict, Secure, HttpOnly cookies.

I feel like authentication these days has veered way too much towards the extreme of security over usability.<p>My primary email account, bank accounts, medical records, etc. absolutely should be protected with MFA (and ironically often are not).<p>But why do I need to do to a 2FA song-and-dance to access a random Zoom meeting? Each of a dozen different Slack workspaces? Why is my GitHub personal project with 2 stars and zero collaborators locked behind a convoluted system of tokens I&#x27;ve been repeatedly asked to regenerate?<p>The thing is, well north of 90% of my daily logins are to services where it would be annoying, but not life-changing, if I got hacked. I&#x27;d rather accept the possibility and consequences of such a black swan event than pay the constant premiums on my time and focus required by today&#x27;s authentication patterns.

&quot;Why Single Sign on Sucks?&quot; Because it&#x27;s not kerberos.<p>I just saw fedora 35&#x27;s installation and it actually wants your login from either google&#x2F;something else&#x2F;etc (calling &quot;enterprise login&quot;)... they actually hid the way to make a local account. smh. what a failure.

Article does a decent job of calling out some usability issues with SSO, but doesn&#x27;t investigate the impact of these usability issues on security. Security and usability are often in tension - if we&#x27;re going to improve usability, our proposed changes <i>also</i> need to improve security, or they&#x27;re dead on arrival. (which is incidentally how we got to this place of horrendous usability)<p>Indeed, there are some material security issues with the real life corporate SSO experience described in the article. For example, users habituate to frequent authentication requests, so they click through them blindly, which opens the door for phishing.

I think this experience can be significantly improved by using the w3c distributed identity[1] + verifiable credentials[2] mechanisms.<p>These are quite young but in my opinion are the identity layer that the web never had and let us to all of the broken experiences that OP discusses well in their article.<p>[1]<a href="https:&#x2F;&#x2F;w3c.github.io&#x2F;did-core&#x2F;" rel="nofollow">https:&#x2F;&#x2F;w3c.github.io&#x2F;did-core&#x2F;</a><p>[2]<a href="https:&#x2F;&#x2F;www.w3.org&#x2F;TR&#x2F;vc-data-model&#x2F;#what-is-a-verifiable-credential" rel="nofollow">https:&#x2F;&#x2F;www.w3.org&#x2F;TR&#x2F;vc-data-model&#x2F;#what-is-a-verifiable-cr...</a>

My grief is having a plethora of phone authenticor apps and now the loss of my phone (even being out of power or just switched off) is catastrophic.

Reminds me of the &quot;create an account or login with Facebook&#x2F;Google&#x2F;etc&quot; UX you see on many sites.<p>The promise was that services could outsource their account management to e.g. Facebook, users wouldn&#x27;t have to deal with dozens of accounts and Facebook gets some more juicy user data to analyse. Win-win-win, right?<p>Except of course sites don&#x27;t <i>want</i> to outsource their account management to anyone. User accounts are valuable, so every company who can manage to do so in any way pushes their users to make an account. They also want to keep maximum control over those accounts.<p>However, what sites would like very much is to have their user accounts associated with a Facebook or Google identity.<p>So what happens in the end is that the buttons really mean &quot;login with Facebook <i>and</i> create an account&quot; - which means for UX and privacy of users, it&#x27;s the worst of both worlds combined.

&gt; In an ideal world, I would log into the computer, login to my SSO solution<p>No in an ideal world, you would log into your computer, and never be bothered again.

SSO using TLS client certificates would be ideal if the support for it in browsers wasn&#x27;t so terrible. The UI is bad, support isn&#x27;t universal, features (like &lt;keygen&gt;) keep getting dropped etc.

Oh lord no. He&#x27;s not wrong about SSO tears at the seams (even though he gets lots of finicky details wrong), but client certs are decidedly not the solution.

In my experience, SSO usually means &quot;same sign on&quot;, meaning you get to use the same credentials across many different services. That&#x27;s certainly an improvement over having to create and manage multiple accounts, but I would never expect to log in once to my computer and then not have to log in again as I access many services.

God damn website! I am reading a blog post, you idiot.

downstream SSO consumers sure do like to expire em quickly and idk why. using jumpcloud SSO with several sites is not painful, aside from things like github hiding a tiny line saying &quot;sign on w sso&quot; and making the tables where stuff would be shown empty so it&#x27;s initially easy to miss you&#x27;re not fully signed in. like just kick me to full sso button screen instead of showing a bunch of stuff i cant interact with until i click that banner

Why don&#x27;t people just use webauthn?

Very interesting article.