15 ms·

Why Single Sign on Sucks

185 points by benarent 5y ago

deleted 5y ago
[deleted]
0xbadcafebee 5y ago
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 "Log In" 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. 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/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'm off to the races. 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 super duper secure? No. But is it better than me typing my password, hitting submit, getting a text message, and typing a code in? Absolutely. The same pattern can totally work across multiple sites. The standards just need to be changed to allow it to happen. This isn't a technical problem, it's a political one.
- SteveNuts 5y ago
  The problem is it's much more complex to manage N users in N applications, having a central location to onboard and offboard your users is a huge boon to IT departments. The convenience isn't for you as the user.
  - Spivak 5y ago
    That's central identity management -- related to, but fundamentally orthogonal to sign in once be signed in everywhere. SSO without central identify management would be weird but also very possible.
- mindslight 5y ago
  Sounds ripe for some additional automation involving a synthetic fingerprint mounted on an actuator, and some image recognition to know when to lower it onto the phone.
- gkop 5y ago
  As an enterprise cloud software business, I will not allow my systems to handle user-chosen long-lived credentials like the passwords you describe. Sorry, it's too much of liability. Got any other ideas? (sincerely curious)
  - pyrale 5y ago
    At some point, your user also has right to make their own policies. Imagine your banker requiring you to take a drug test before they let you do any action, would that be fine by you? If you were talking about your employees, of course, it's less of an issues, but you are still open to them misusing other solutions: in the end, invasive security policies in a business where people can also use service accounts is a recipe to have people build backdoors in their own security. Good security is only as secure as it is convenient for users. When I was working in banking, people had physical card readers that would identify them. Of course, some people still forgot them sometimes, but it was also necessary to get out of the desks.
    - gkop 5y ago
      I'm not following you but very curious! I have no issues getting my enterprise customers to configure SSO, so there's no practical reason for me to support password login. In the consumer space, which is not my area of expertise, it seems that combinations of "passwordless" and OAuth are working for successful companies. Where is the last bastion of places where a user can justifiably demand a password login option? What do you mean by invasive security practices?
      - pyrale 5y ago
        (I made some edits to the previous post, as I figured out you may have talked about people working with you rather than clients) > I have no issues getting my enterprise customers to configure SSO, so there's no practical reason for me to support password login. I'm not really sure what you mean when you say SSO. We use Google workspace at work, and use the sso in several of our products. Still, since workspace admin prompts us to relog every damn time, some colleagues use the service account to perform workspace actions. That's a hole of course, as the service account is not supposed to be used for user actions, but it's also more convenient. Another example, of which I'm guilty, was my previous work's VPN 2FA policy, which my team conveniently skipped with a script doing the oauth call. Of course, not everyone did the script properly (because prompting for your password takes a couple more lines), and so some of us may have had their credentials in the bash file. This kind of shortcuts is hard to avoid for technical users, and so the golden rule for security in my opinion is that it should be easier to do the right thing. Unfortunately, each person has a different definition of friction, so it's not an easy topic. > What do you mean by invasive security practices? It's obviously a personal criterion. To me, invasive starts when people want to get in my phone. It's not really arbitrary, since my phone is a piece of garbage that has no security, but it's a personal thing since others may prefer to have a phone solution.
deergomoo 5y ago
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's going to be much less of a headache than managing n sets of user credentials.
- throwawayboise 5y ago
  That's centralized identity management, not single-sign-on. Single-sign-on is/was supposed to mean you sign on once. I've never seen it actually work.
  - Spivak 5y ago
    Yeah, the manifestation of "LDAP Integrated" still means you have to sign into every single service, it just uses the same credentials.
  - hinkley 5y ago
    SSO is the source of truth, and centralized identity is the system of record. They go hand in glove. It's not a non-sequitur so much as a tangent.
    - gkop 5y ago
      for the benefit of others (I had to search it): https://www.linkedin.com/pulse/difference-between-system-record-source-truth-santosh-kudva/ https://www.linkedin.com/pulse/difference-between-system-rec...
  - Jenk 5y ago
    SSO can be both Single Sign-On, or Same Sign-On. The latter is the LDAP integrated thing - (re)using the same credentials for multiple/disparate services, controlled centrally. The former ("true" single sign-on) is logging in once and accessing everything from there. FWIW there are single sign-on services out there. Okta is used by my current employer, I log into the Okta portal and it has links out to all of the services it supports from there.
csben 5y ago
My experience is completely opposite of the author's. I sign on once a day when I access a service that uses my firm's SSO solution. I'm then automatically signed in to all other services as I use them. It's quite seamless. I have no complaints about the SSO setup in my firm.
- throwawayboise 5y ago
  So your company doesn't have certain functions where someone has said "this is really critical so we'll force a sign-in even if the SSO token is already there" because that happens to me 10 times a day at my work.
  - Spivak 5y ago
    Which is silly because if you do that you're basically admitting that your SSO isn't fulfilling its promise of identifying the user. If you are having the thought, "what if the user I authed isn't the user anymore" then you should be reauthing them for any service at that point.
    - seanp2k2 5y ago
      Almost as fun as when TSA uses logic like “we thought you were going to hijack a plane using those nail clippers, but now that we’ve made you throw them away, you can board with no further scrutiny! Crisis averted!”
  - pyrale 5y ago
    I would say that's not really a SSO issue so much as it's an obnoxious session duration policy.
  - csben 5y ago
    Yes, this does happen. Especially for HR related matters. But that's definitely more of an exception than the rule. For most services that I use on a day-to-day basis, the experience is seamless.
  - derekp7 5y ago
sitzkrieg 5y ago
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 "sign on w sso" and making the tables where stuff would be shown empty so it's initially easy to miss you'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
jFriedensreich 5y ago
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.
wereHamster 5y ago
> While it’s possible to create cookie with credentials, this should be avoided due to all the possibilities of CSRF Attacks This is no longer an issue, if you use SameSite=Strict, Secure, HttpOnly cookies.
gkop 5y ago
Article does a decent job of calling out some usability issues with SSO, but doesn't investigate the impact of these usability issues on security. Security and usability are often in tension - if we're going to improve usability, our proposed changes also need to improve security, or they're dead on arrival. (which is incidentally how we got to this place of horrendous usability) 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.
- Aeolun 5y ago
  My pet peeve is having to change my password every 3 months. I can practically guarantee all the employees use some form of incrementing number.
  - gkop 5y ago
    Don't get me started...
  - seanp2k2 5y ago
    1. Try passwords until you get locked out 2. Engage with IT to unlock 3. Reset password flow 4. Iterate on new password as the complexity requirements you fail are slowly revealed to you 5. “Password cannot be the same as previous n passwords” 6. End up with an even more forgettable variation 7. Sign in again across all your now-invalid sessions across a dozen apps and devices. 8. Apply liberal amounts of 2FA + push-based and email or txt confirmations to the above for extra hate from users. 9. Repeat forever because obviously there is no better way to do this, but GraphQL and NFTs are going to save the world, let’s work on those instead!
- Sebb767 5y ago
  > Security and usability are often in tension - if we're going to improve usability, our proposed changes also need to improve security, or they're dead on arrival. I'd actually say it's the other way around. One of my favorite quote related to that is "security at the expense of usability is at the expense of security". If you force users to rotate passwords, they'll use some form of continuous passwords and/or stick them with notes to their monitors. If you'd need to sign in all the time, users will be less careful and choose easier passwords. If it takes 20 seconds to authenticate at the front door, it will only take a few days until someone puts a brick there to keep it open. To improve security, you'll absolutely need to consider the UX; improving the UX while not caring about security, OTOH, works quite well in my experience (until it blows up in your face, which might be years away or even a moral hazard).
smitty1e 5y ago
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.
- hsbauauvhabzb 5y ago
  This. I recently got a new iPhone, most auth tokens didn’t xfer across (presumably they’re in the Secure Enclave). I’m root in some services including azure and aws tenancies. I have no idea what would happen if I lose my phone, as opposed to replacing it with the old phone next to me for a month for this exact use case
  - mooreds 5y ago
    The solutions I've heard of usually involve a screenshot of the seed QR code stored in a safe somewhere. Not optimal, but at least gives you a backup in case of disaster.
    - vetinari 5y ago
      You can "read" the qr code, extract the TOTP seed and put it into app like bitwarden, where it would be both backed up and can generate the login codes too. The problem are sites or services, that do use their own variations instead of standard.
    - hsbauauvhabzb 5y ago
      This doesn’t work for push based auth, unsure if they support Totp fallback though
  - petepete 5y ago
    I had this worry too, I now use Bitwarden for my phone authenticator app needs. Everything's safe, backed up and I need my Yubikey to unlock it. I can use it from my computer too, which is a side benefit.
- toastal 5y ago
  Agreed, this is real dumb due to how heavy phone usage tends to be, it's something that breaks frequently. It drives me mad when some services like TransferWise use a proprietary in-app OTP instead of TOTP that I can back up easily to password-store and hardware key.
EGreg 5y ago
Why don't people just use webauthn?
- hsbauauvhabzb 5y ago
  This is incredibly naive, you have to consider support of both applications and help desks, and the cost of those.
- jrockway 5y ago
  I went this route. I really like the design of Google's Identity-Aware Proxy. You host your apps behind it, the proxy authenticates users and passes a JWT to the application that contains additional metadata. The app can choose to care or not care about the JWT. This is nice for read-only things that aren't particularly important (something like jaeger-ui). Or the app can choose to care, and do one cryptographic operation to get a trustworthy username and group membership list. This is so much easier from an operations and implementation perspective than integrating something like OIDC. I wish more applications supported this, and didn't force me to hack OIDC into this flow. As for WebAuthn, yes, that's what you should be using these days. People are terrible at choosing passwords, so why make them? I wrote an authenticating proxy that maintains username -> WebAuthn credentials, and use it for my personal projects. I wouldn't recommend that someone else use it (incomplete featureset, not security reviewed), but it's totally open source so you can steal the bits you like: https://github.com/jrockway/jsso2 https://github.com/jrockway/jsso2 The end result is that I can open up Grafana on my phone and sign in with FaceID. Or if my face falls off, I can scan my YubiKey with NFC. All given to you for free for using WebAuthn. And it costs $0/month, which is much less than the Oktas of the world charge for a more
- jeroenhd 5y ago
  My desktop doesn't have a webauthn capable secure backing so I'd have to fake one. Maybe the TPM in it can work for that, but I haven't seen browsers leverage that opportunity yet. This means that unlike my phone, my desktop always requires some annoying fallback. For U2F I've configured Krypt, which uses my phone as a U2F key, but that doesn't work for webauthn (yet?). This means I'm always filling in password forms for services that also offer webauthn as an option, at least when logging in from my desktop. The fact I need to go through some form of recovery process to register a device for every browser I use (and, in case of temporary logins on borrowed devices, removing the session again) is also rather annoying. Then there's the fact that webauthn is only a single factor, and there are real benefits to 2FA. Stolen/mirrored phones at airports of oppressive regimes are a credible threat depending on the business you're serving, so it's essential to have a 2FA option in some form. As webauthn is the "something you have" part of the traditional factors, that means you're either supposed to implement biometrics or some kind of password as a second factor. At that point webauthn is practically U2F with a built in username. There are also certifications they require your company to use 2FA regardless of the level of security your IT team thinks it needs. You can probably explain away the need for 2FA but I don't think the legal/compliance people in your company will be happy with you if you make them try that. I'm all for webauthn, but "just use webauthn" isn't a generic fix. It's great for simple services like chat apps, forums, things like HN, you name it, but for business logins there are often requirements that take away a lot of the benefits to the system.
zaptheimpaler 5y ago
I thought my signin woes were finally solved after moving everything over to 1Password. It works great and auto-fills usernames/passwords and TOTPs with a shortcut. 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. 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 "omg client certificates are insecure" and we can migrate to some other crap again. 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 "once a day SSO is insecure"..
- Johnny555 5y ago
  I thought my signin woes were finally solved after moving everything over to 1Password. It works great and auto-fills usernames/passwords and TOTPs with a shortcut. Doesn't that dilute the value of MFA and essentially make it SFA? If someone compromises your 1Password app or password, then they get both factors of authentication. what if an employee leaves their laptop unattended I think that's what automatic screen locks are supposed to protect from, my company enforces a 5 minute screen lock. I used to use a bluetooth screen lock that would lock my screen immediately if I stopped away from the computer, but the company now won't let me use that app because it has the capability to automatically unlock when I come back (though I don't use that part).
  - zaptheimpaler 5y ago
    > Doesn't that dilute the value of MFA and essentially make it SFA? If someone compromises your 1Password app or password, then they get both factors of authentication. Yep, that's the point. I have been using the internet for 20 years now and have somehow managed to not get hacked by using unique passwords, not clicking on porn pop ups or falling for phishing attacks and updating my OS occasionally. I take a risk every time I drive a car or drink alcohol or even walk around my neighborhood. We can't bubble wrap the entire world and make risk disappear. So i like SFA because its convenient, even if it may be marginally more risky. I literally cannot imagine a solution with 0 risk, and its foolish to keep moving to new security "best-practices" trying to pretend one exists.
bvrmn 5y ago
SSO sucks nothing in compare with TOTP-incompatible "please scan QR" mobile auth. With uniq app per service.
- politelemon 5y ago
  Sendgrid does something similar. You can't use TOTP, you have use Authy specifically for their special 7 digit code. It's infuriating and they don't care.
- tomjen3 5y ago
  Yeah, I don't know how many services say "please enable TFA" and then don't support my yubikey. AWS takes the cake - you can enable a youbikey, or other TFA, but only one. So I get locked out if my device ever dies.
XorNot 5y ago
This is the problem Kerberos solved. It solved it well. 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. When it works, it works really well, but absolutely no one implements support for it.
- vetinari 5y ago
  Oh yes, somebody implements it, many certainly heard of Active Directory ;) (or maybe even of FreeIPA). However, it is not really safe to expose it publicly, so it is stuck to intranet only. Random services can ask the user for a ticket (domain does not have to match the realm!), so in your browser you need to whitelist hosts that are allowed to ask for SPNEGO. It does not help that both mobile platforms and macOS insist on using MDM to join the domain. So if you manage to skip all the hurdles, you can use SSO like Keycloak that does accept SPNEGO for the user login and use it for SAML2/OIDC for all the other services. This way, your ad-joined-desktop/gnome-online-accounts/nomad.app login can work in the brave new world of web apps and apis outside your intranet.
  - XorNot 5y ago
    There's not really much evidence that Kerberos was ever insecure to expose publicly - this seems to be more heresay then any actual problem. The biggest problem is the client setup story - and that honestly has more to do with the very inconsistent support in the application space then any real restrictions. It's "enterprisey" and has no story where the user owns their own device (then again so is SSO and Microsoft would like all Windows machines to be joined to the big microsoft.com realm in the sky anyway).
seiferteric 5y ago
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/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/session cookie should be good enough right?
- alar44 5y ago
  VPN is easier to set up, manage, and troubleshoot. Connect to LDAP, set up groups, flip the switch, done. You'll have to use it for vendor or 3rd party access anyway, so may as well use it for the rest of the org.
- benarent 5y ago
  OP here: We are cooking up something cool at Teleport, drop me an email ben@goteleport.com and I'll invite you to the preview.
  - seiferteric 5y ago
    Oh, I didn't make it to the bottom of the article lol, I see that is what this is about.... cool!
- jeroenhd 5y ago
  I think it's because A) developers don't know about it, B) users don't understand it and C) the UI for it is quite terrible. Implementing it requires some uncommon TLS configuration and a little cert work. Using it prompts uncommon native popups, slowing people down. Failure leads to weird redirects for which you can't really fall back to a login prompt because the auth happens on TLS level and a token in HTTP can't replace that. Having to install a certificate per browser per device is kind of a pain, at least password managers solve that. There's no reason password managers couldn't also sync certificates, but the functionality simply isn't there yet. TLS auth is definitely the cleanest solution from a technical point of view; the stateless HTTP layer doesn't need to track auth, it just gets the necessary information from the layers underneath it. Sadly, its lack of popularity means it's seen very little love from developers the last ten years.
paxys 5y ago
The author's complaint is really against authentication in general rather than SSO. Different sites and services have always and will always use their own authn/authz methods, simply because it isn't a generic problem that can be abstracted away. You can outsource parts of it (show the user a username/password form, validate credentials, verify email, check 2FA) which is what all these SSO providers aim to do. Also the examples they mention are all just badly configured applications, which can easily be fixed.
- gonehome 5y ago
  I think it could be a generic problem that's abstracted away, but you have to absorb identity into the stack at the OS level. For a centralized authoritarian example of this you can consider WeChat. Unified API and auth layer that supports lots of different applications from one auth service that's used for basically everything. In the decentralized world there have been attempts to do this as hacks on the existing web (stuff like open id), but they can't really succeed on the current stack. The Urbit OS is an attempt to solve these types of issues by boiling the ocean and in doing so this is one of the issues that gets fixed.
  - Anunayj 5y ago
    I agree, honestly something like public key auth built into the browser seems great to me! I use a single ssh key to login into multiple servers, I don't have to rely on a central authority to identify me and anyone can remove my access by just removing my public key.
- bfung 5y ago
  Same - I sign in once and all the other apps is a click away. From the author’s gifs, it looks like their SSO is setup incorrectly AND being incorrectly used. The 1st gif is really bad, the subsequent ones are more typical SSO setups. Also, this blog article is an ad for Teleport. Given their flawed premise, … yeah.
adontz 5y ago
GitHub's SSO if it's not Enterprise managed accounts sucks. Thus the example is extremely unlucky. 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'll have john.smith@example.com username. What GitHub does is it links enterprise identity to personal account. So I have to log in twice (and honestly it'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'm visible as HugeDick53 and john.smith@example.com identity vanishes from view. GitHub's justification is that contributions on enterprise projects should be visible on personal accounts. However, from administrator'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. On the other hand Atlassian products provide true SSO. Not the most sophisticated one, but at least it's SSO.
- zrail 5y ago
  I make a new GitHub account with work email on day one. My personal GitHub account never touches my work machines and the only personal thing my work accounts touch is my dotfiles.
  - rectang 5y ago
    Creating separate Github accounts for each employer/organization is crucial to avoid creating a personal access token for one organization which has global permissions across all repositories your account has access to. This has been a problem for many years. Note that Github only allows one free account, so the business needs to pay for each one if its dev accounts.
- stormbrew 5y ago
  Honestly, at the risk of committing No True Scotsman, I feel like the flow demonstrated in this blog post just.. isn't SSO to begin with, actually. It may be using SSO infrastructure, but if you have to login twice, use 2fa twice, to log in to one thing, then it's Two Sign On or something. So while I don't think the thrust of the post is wrong in general, it's an odd example. > GitHub's justification is that contributions on enterprise projects should be visible on personal accounts. Really the thing that sucks here is something that hasn't really been well solved and is only tangentially related to SSO: Multiple linked identities under one or more logical accounts. No site does this well, and SSO is an insufficient tool to help - the entire mechanism of identity on the web is working against it.
amanzi 5y ago
In my experience, SSO usually means "same sign on", meaning you get to use the same credentials across many different services. That'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.
evouga 5y ago
I feel like authentication these days has veered way too much towards the extreme of security over usability. My primary email account, bank accounts, medical records, etc. absolutely should be protected with MFA (and ironically often are not). 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've been repeatedly asked to regenerate? 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'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's authentication patterns.
jiveturkey 5y ago
Oh lord no. He'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.
cletus 5y ago
Weird timing. I was just dealing with an issue related to this. 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's page. Why? I guessed I'd signed on to my corp Google account on my phone at some point and it remembered. Googling didn'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. This is a terrible user experience. But even when you are signed in to more than one account it's terrible. You get a link to a Google doc, click on it and it says "you don't have permission". 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 "Request Access" and are confused why it doesn't work. I haven't experienced the author's issue of 43 sign-ons a day. Sounds like a bad enterprise setup. I'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's terrible. More often than not I find myself segragating Google accounts by browser (or browser profile). That's a pretty clear sign the product experience, well, sucks.
- ElFitz 5y ago
  I just hate it when clients / employers try to get me to use a Google account. If not careful, set it up once, in one place (ie email), and you’ll get logged into that account for every single Google app on your iPhone. No, Google, I don’t want to use Google Maps with some random account some client set up for me. I just want to get their emails. Nothing more. Then, of course, there’s trying to join a Google Meet meeting, and having to play around with the Google account selection. But the funniest was when I had my own GSuite org, with almost every service turned off. I’d get redirected to the admin panel, but then switching to the client’s org’s account would redirect to their admin panel, to which I didn’t have access. And getting back to the initial app (drive or meet), would bring me back into the account linked to my org, thus the admin panel… After a couple times, I ended up systematically opening those links in a private browsing window.
throw7 5y ago
"Why Single Sign on Sucks?" Because it's not kerberos. I just saw fedora 35's installation and it actually wants your login from either google/something else/etc (calling "enterprise login")... they actually hid the way to make a local account. smh. what a failure.
nichochar 5y ago
I think this experience can be significantly improved by using the w3c distributed identity[1] + verifiable credentials[2] mechanisms. 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. [1]https://w3c.github.io/did-core/ https://w3c.github.io/did-core/ [2]https://www.w3.org/TR/vc-data-model/#what-is-a-verifiable-credential https://www.w3.org/TR/vc-data-model/#what-is-a-verifiable-cr...
pabs3 5y ago
SSO using TLS client certificates would be ideal if the support for it in browsers wasn't so terrible. The UI is bad, support isn't universal, features (like <keygen>) keep getting dropped etc.
Danielle69 5y ago
[dead]
minroot 5y ago
God damn website! I am reading a blog post, you idiot.
perryizgr8 5y ago
> In an ideal world, I would log into the computer, login to my SSO solution No in an ideal world, you would log into your computer, and never be bothered again.
xg15 5y ago
Reminds me of the "create an account or login with Facebook/Google/etc" UX you see on many sites. The promise was that services could outsource their account management to e.g. Facebook, users wouldn't have to deal with dozens of accounts and Facebook gets some more juicy user data to analyse. Win-win-win, right? Except of course sites don't want 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. However, what sites would like very much is to have their user accounts associated with a Facebook or Google identity. So what happens in the end is that the buttons really mean "login with Facebook and create an account" - which means for UX and privacy of users, it's the worst of both worlds combined.
penguinista 5y ago
Very interesting article.

185 points by benarent 5y ago

deleted 5y ago

[deleted]

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 "Log In" 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. 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/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'm off to the races. 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 super duper secure? No. But is it better than me typing my password, hitting submit, getting a text message, and typing a code in? Absolutely. The same pattern can totally work across multiple sites. The standards just need to be changed to allow it to happen. This isn't a technical problem, it's a political one.

SteveNuts 5y ago
The problem is it's much more complex to manage N users in N applications, having a central location to onboard and offboard your users is a huge boon to IT departments. The convenience isn't for you as the user.
- Spivak 5y ago
  That's central identity management -- related to, but fundamentally orthogonal to sign in once be signed in everywhere. SSO without central identify management would be weird but also very possible.
mindslight 5y ago
Sounds ripe for some additional automation involving a synthetic fingerprint mounted on an actuator, and some image recognition to know when to lower it onto the phone.
gkop 5y ago
As an enterprise cloud software business, I will not allow my systems to handle user-chosen long-lived credentials like the passwords you describe. Sorry, it's too much of liability. Got any other ideas? (sincerely curious)
- pyrale 5y ago
  At some point, your user also has right to make their own policies. Imagine your banker requiring you to take a drug test before they let you do any action, would that be fine by you? If you were talking about your employees, of course, it's less of an issues, but you are still open to them misusing other solutions: in the end, invasive security policies in a business where people can also use service accounts is a recipe to have people build backdoors in their own security. Good security is only as secure as it is convenient for users. When I was working in banking, people had physical card readers that would identify them. Of course, some people still forgot them sometimes, but it was also necessary to get out of the desks.
  - gkop 5y ago
    I'm not following you but very curious! I have no issues getting my enterprise customers to configure SSO, so there's no practical reason for me to support password login. In the consumer space, which is not my area of expertise, it seems that combinations of "passwordless" and OAuth are working for successful companies. Where is the last bastion of places where a user can justifiably demand a password login option? What do you mean by invasive security practices?
    - pyrale 5y ago
      (I made some edits to the previous post, as I figured out you may have talked about people working with you rather than clients) > I have no issues getting my enterprise customers to configure SSO, so there's no practical reason for me to support password login. I'm not really sure what you mean when you say SSO. We use Google workspace at work, and use the sso in several of our products. Still, since workspace admin prompts us to relog every damn time, some colleagues use the service account to perform workspace actions. That's a hole of course, as the service account is not supposed to be used for user actions, but it's also more convenient. Another example, of which I'm guilty, was my previous work's VPN 2FA policy, which my team conveniently skipped with a script doing the oauth call. Of course, not everyone did the script properly (because prompting for your password takes a couple more lines), and so some of us may have had their credentials in the bash file. This kind of shortcuts is hard to avoid for technical users, and so the golden rule for security in my opinion is that it should be easier to do the right thing. Unfortunately, each person has a different definition of friction, so it's not an easy topic. > What do you mean by invasive security practices? It's obviously a personal criterion. To me, invasive starts when people want to get in my phone. It's not really arbitrary, since my phone is a piece of garbage that has no security, but it's a personal thing since others may prefer to have a phone solution.

deergomoo 5y ago

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's going to be much less of a headache than managing n sets of user credentials.

throwawayboise 5y ago
That's centralized identity management, not single-sign-on. Single-sign-on is/was supposed to mean you sign on once. I've never seen it actually work.
- Spivak 5y ago
  Yeah, the manifestation of "LDAP Integrated" still means you have to sign into every single service, it just uses the same credentials.
- hinkley 5y ago
  SSO is the source of truth, and centralized identity is the system of record. They go hand in glove. It's not a non-sequitur so much as a tangent.
  - gkop 5y ago
    for the benefit of others (I had to search it): https://www.linkedin.com/pulse/difference-between-system-record-source-truth-santosh-kudva/ https://www.linkedin.com/pulse/difference-between-system-rec...
- Jenk 5y ago
  SSO can be both Single Sign-On, or Same Sign-On. The latter is the LDAP integrated thing - (re)using the same credentials for multiple/disparate services, controlled centrally. The former ("true" single sign-on) is logging in once and accessing everything from there. FWIW there are single sign-on services out there. Okta is used by my current employer, I log into the Okta portal and it has links out to all of the services it supports from there.

csben 5y ago

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

throwawayboise 5y ago
So your company doesn't have certain functions where someone has said "this is really critical so we'll force a sign-in even if the SSO token is already there" because that happens to me 10 times a day at my work.
- Spivak 5y ago
  Which is silly because if you do that you're basically admitting that your SSO isn't fulfilling its promise of identifying the user. If you are having the thought, "what if the user I authed isn't the user anymore" then you should be reauthing them for any service at that point.
  - seanp2k2 5y ago
    Almost as fun as when TSA uses logic like “we thought you were going to hijack a plane using those nail clippers, but now that we’ve made you throw them away, you can board with no further scrutiny! Crisis averted!”
- pyrale 5y ago
  I would say that's not really a SSO issue so much as it's an obnoxious session duration policy.
- csben 5y ago
  Yes, this does happen. Especially for HR related matters. But that's definitely more of an exception than the rule. For most services that I use on a day-to-day basis, the experience is seamless.
- derekp7 5y ago

sitzkrieg 5y ago

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 "sign on w sso" and making the tables where stuff would be shown empty so it's initially easy to miss you'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

jFriedensreich 5y ago

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.

wereHamster 5y ago

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

gkop 5y ago

Article does a decent job of calling out some usability issues with SSO, but doesn't investigate the impact of these usability issues on security. Security and usability are often in tension - if we're going to improve usability, our proposed changes also need to improve security, or they're dead on arrival. (which is incidentally how we got to this place of horrendous usability) 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.

Aeolun 5y ago
My pet peeve is having to change my password every 3 months. I can practically guarantee all the employees use some form of incrementing number.
- gkop 5y ago
  Don't get me started...
- seanp2k2 5y ago
  1. Try passwords until you get locked out 2. Engage with IT to unlock 3. Reset password flow 4. Iterate on new password as the complexity requirements you fail are slowly revealed to you 5. “Password cannot be the same as previous n passwords” 6. End up with an even more forgettable variation 7. Sign in again across all your now-invalid sessions across a dozen apps and devices. 8. Apply liberal amounts of 2FA + push-based and email or txt confirmations to the above for extra hate from users. 9. Repeat forever because obviously there is no better way to do this, but GraphQL and NFTs are going to save the world, let’s work on those instead!
Sebb767 5y ago
> Security and usability are often in tension - if we're going to improve usability, our proposed changes also need to improve security, or they're dead on arrival. I'd actually say it's the other way around. One of my favorite quote related to that is "security at the expense of usability is at the expense of security". If you force users to rotate passwords, they'll use some form of continuous passwords and/or stick them with notes to their monitors. If you'd need to sign in all the time, users will be less careful and choose easier passwords. If it takes 20 seconds to authenticate at the front door, it will only take a few days until someone puts a brick there to keep it open. To improve security, you'll absolutely need to consider the UX; improving the UX while not caring about security, OTOH, works quite well in my experience (until it blows up in your face, which might be years away or even a moral hazard).

smitty1e 5y ago

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.

hsbauauvhabzb 5y ago
This. I recently got a new iPhone, most auth tokens didn’t xfer across (presumably they’re in the Secure Enclave). I’m root in some services including azure and aws tenancies. I have no idea what would happen if I lose my phone, as opposed to replacing it with the old phone next to me for a month for this exact use case
- mooreds 5y ago
  The solutions I've heard of usually involve a screenshot of the seed QR code stored in a safe somewhere. Not optimal, but at least gives you a backup in case of disaster.
  - vetinari 5y ago
    You can "read" the qr code, extract the TOTP seed and put it into app like bitwarden, where it would be both backed up and can generate the login codes too. The problem are sites or services, that do use their own variations instead of standard.
  - hsbauauvhabzb 5y ago
    This doesn’t work for push based auth, unsure if they support Totp fallback though
- petepete 5y ago
  I had this worry too, I now use Bitwarden for my phone authenticator app needs. Everything's safe, backed up and I need my Yubikey to unlock it. I can use it from my computer too, which is a side benefit.
toastal 5y ago
Agreed, this is real dumb due to how heavy phone usage tends to be, it's something that breaks frequently. It drives me mad when some services like TransferWise use a proprietary in-app OTP instead of TOTP that I can back up easily to password-store and hardware key.

EGreg 5y ago

Why don't people just use webauthn?

hsbauauvhabzb 5y ago
This is incredibly naive, you have to consider support of both applications and help desks, and the cost of those.
jrockway 5y ago
I went this route. I really like the design of Google's Identity-Aware Proxy. You host your apps behind it, the proxy authenticates users and passes a JWT to the application that contains additional metadata. The app can choose to care or not care about the JWT. This is nice for read-only things that aren't particularly important (something like jaeger-ui). Or the app can choose to care, and do one cryptographic operation to get a trustworthy username and group membership list. This is so much easier from an operations and implementation perspective than integrating something like OIDC. I wish more applications supported this, and didn't force me to hack OIDC into this flow. As for WebAuthn, yes, that's what you should be using these days. People are terrible at choosing passwords, so why make them? I wrote an authenticating proxy that maintains username -> WebAuthn credentials, and use it for my personal projects. I wouldn't recommend that someone else use it (incomplete featureset, not security reviewed), but it's totally open source so you can steal the bits you like: https://github.com/jrockway/jsso2 https://github.com/jrockway/jsso2 The end result is that I can open up Grafana on my phone and sign in with FaceID. Or if my face falls off, I can scan my YubiKey with NFC. All given to you for free for using WebAuthn. And it costs $0/month, which is much less than the Oktas of the world charge for a more
jeroenhd 5y ago
My desktop doesn't have a webauthn capable secure backing so I'd have to fake one. Maybe the TPM in it can work for that, but I haven't seen browsers leverage that opportunity yet. This means that unlike my phone, my desktop always requires some annoying fallback. For U2F I've configured Krypt, which uses my phone as a U2F key, but that doesn't work for webauthn (yet?). This means I'm always filling in password forms for services that also offer webauthn as an option, at least when logging in from my desktop. The fact I need to go through some form of recovery process to register a device for every browser I use (and, in case of temporary logins on borrowed devices, removing the session again) is also rather annoying. Then there's the fact that webauthn is only a single factor, and there are real benefits to 2FA. Stolen/mirrored phones at airports of oppressive regimes are a credible threat depending on the business you're serving, so it's essential to have a 2FA option in some form. As webauthn is the "something you have" part of the traditional factors, that means you're either supposed to implement biometrics or some kind of password as a second factor. At that point webauthn is practically U2F with a built in username. There are also certifications they require your company to use 2FA regardless of the level of security your IT team thinks it needs. You can probably explain away the need for 2FA but I don't think the legal/compliance people in your company will be happy with you if you make them try that. I'm all for webauthn, but "just use webauthn" isn't a generic fix. It's great for simple services like chat apps, forums, things like HN, you name it, but for business logins there are often requirements that take away a lot of the benefits to the system.

zaptheimpaler 5y ago

I thought my signin woes were finally solved after moving everything over to 1Password. It works great and auto-fills usernames/passwords and TOTPs with a shortcut. 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. 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 "omg client certificates are insecure" and we can migrate to some other crap again. 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 "once a day SSO is insecure"..

Johnny555 5y ago
I thought my signin woes were finally solved after moving everything over to 1Password. It works great and auto-fills usernames/passwords and TOTPs with a shortcut. Doesn't that dilute the value of MFA and essentially make it SFA? If someone compromises your 1Password app or password, then they get both factors of authentication. what if an employee leaves their laptop unattended I think that's what automatic screen locks are supposed to protect from, my company enforces a 5 minute screen lock. I used to use a bluetooth screen lock that would lock my screen immediately if I stopped away from the computer, but the company now won't let me use that app because it has the capability to automatically unlock when I come back (though I don't use that part).
- zaptheimpaler 5y ago
  > Doesn't that dilute the value of MFA and essentially make it SFA? If someone compromises your 1Password app or password, then they get both factors of authentication. Yep, that's the point. I have been using the internet for 20 years now and have somehow managed to not get hacked by using unique passwords, not clicking on porn pop ups or falling for phishing attacks and updating my OS occasionally. I take a risk every time I drive a car or drink alcohol or even walk around my neighborhood. We can't bubble wrap the entire world and make risk disappear. So i like SFA because its convenient, even if it may be marginally more risky. I literally cannot imagine a solution with 0 risk, and its foolish to keep moving to new security "best-practices" trying to pretend one exists.

bvrmn 5y ago

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

politelemon 5y ago
Sendgrid does something similar. You can't use TOTP, you have use Authy specifically for their special 7 digit code. It's infuriating and they don't care.
tomjen3 5y ago
Yeah, I don't know how many services say "please enable TFA" and then don't support my yubikey. AWS takes the cake - you can enable a youbikey, or other TFA, but only one. So I get locked out if my device ever dies.

XorNot 5y ago

This is the problem Kerberos solved. It solved it well. 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. When it works, it works really well, but absolutely no one implements support for it.

vetinari 5y ago
Oh yes, somebody implements it, many certainly heard of Active Directory ;) (or maybe even of FreeIPA). However, it is not really safe to expose it publicly, so it is stuck to intranet only. Random services can ask the user for a ticket (domain does not have to match the realm!), so in your browser you need to whitelist hosts that are allowed to ask for SPNEGO. It does not help that both mobile platforms and macOS insist on using MDM to join the domain. So if you manage to skip all the hurdles, you can use SSO like Keycloak that does accept SPNEGO for the user login and use it for SAML2/OIDC for all the other services. This way, your ad-joined-desktop/gnome-online-accounts/nomad.app login can work in the brave new world of web apps and apis outside your intranet.
- XorNot 5y ago
  There's not really much evidence that Kerberos was ever insecure to expose publicly - this seems to be more heresay then any actual problem. The biggest problem is the client setup story - and that honestly has more to do with the very inconsistent support in the application space then any real restrictions. It's "enterprisey" and has no story where the user owns their own device (then again so is SSO and Microsoft would like all Windows machines to be joined to the big microsoft.com realm in the sky anyway).

seiferteric 5y ago

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/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/session cookie should be good enough right?

alar44 5y ago
VPN is easier to set up, manage, and troubleshoot. Connect to LDAP, set up groups, flip the switch, done. You'll have to use it for vendor or 3rd party access anyway, so may as well use it for the rest of the org.
benarent 5y ago
OP here: We are cooking up something cool at Teleport, drop me an email ben@goteleport.com and I'll invite you to the preview.
- seiferteric 5y ago
  Oh, I didn't make it to the bottom of the article lol, I see that is what this is about.... cool!
jeroenhd 5y ago
I think it's because A) developers don't know about it, B) users don't understand it and C) the UI for it is quite terrible. Implementing it requires some uncommon TLS configuration and a little cert work. Using it prompts uncommon native popups, slowing people down. Failure leads to weird redirects for which you can't really fall back to a login prompt because the auth happens on TLS level and a token in HTTP can't replace that. Having to install a certificate per browser per device is kind of a pain, at least password managers solve that. There's no reason password managers couldn't also sync certificates, but the functionality simply isn't there yet. TLS auth is definitely the cleanest solution from a technical point of view; the stateless HTTP layer doesn't need to track auth, it just gets the necessary information from the layers underneath it. Sadly, its lack of popularity means it's seen very little love from developers the last ten years.

paxys 5y ago

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

gonehome 5y ago
I think it could be a generic problem that's abstracted away, but you have to absorb identity into the stack at the OS level. For a centralized authoritarian example of this you can consider WeChat. Unified API and auth layer that supports lots of different applications from one auth service that's used for basically everything. In the decentralized world there have been attempts to do this as hacks on the existing web (stuff like open id), but they can't really succeed on the current stack. The Urbit OS is an attempt to solve these types of issues by boiling the ocean and in doing so this is one of the issues that gets fixed.
- Anunayj 5y ago
  I agree, honestly something like public key auth built into the browser seems great to me! I use a single ssh key to login into multiple servers, I don't have to rely on a central authority to identify me and anyone can remove my access by just removing my public key.
bfung 5y ago
Same - I sign in once and all the other apps is a click away. From the author’s gifs, it looks like their SSO is setup incorrectly AND being incorrectly used. The 1st gif is really bad, the subsequent ones are more typical SSO setups. Also, this blog article is an ad for Teleport. Given their flawed premise, … yeah.

adontz 5y ago

GitHub's SSO if it's not Enterprise managed accounts sucks. Thus the example is extremely unlucky. 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'll have john.smith@example.com username. What GitHub does is it links enterprise identity to personal account. So I have to log in twice (and honestly it'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'm visible as HugeDick53 and john.smith@example.com identity vanishes from view. GitHub's justification is that contributions on enterprise projects should be visible on personal accounts. However, from administrator'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. On the other hand Atlassian products provide true SSO. Not the most sophisticated one, but at least it's SSO.

zrail 5y ago
I make a new GitHub account with work email on day one. My personal GitHub account never touches my work machines and the only personal thing my work accounts touch is my dotfiles.
- rectang 5y ago
  Creating separate Github accounts for each employer/organization is crucial to avoid creating a personal access token for one organization which has global permissions across all repositories your account has access to. This has been a problem for many years. Note that Github only allows one free account, so the business needs to pay for each one if its dev accounts.
stormbrew 5y ago
Honestly, at the risk of committing No True Scotsman, I feel like the flow demonstrated in this blog post just.. isn't SSO to begin with, actually. It may be using SSO infrastructure, but if you have to login twice, use 2fa twice, to log in to one thing, then it's Two Sign On or something. So while I don't think the thrust of the post is wrong in general, it's an odd example. > GitHub's justification is that contributions on enterprise projects should be visible on personal accounts. Really the thing that sucks here is something that hasn't really been well solved and is only tangentially related to SSO: Multiple linked identities under one or more logical accounts. No site does this well, and SSO is an insufficient tool to help - the entire mechanism of identity on the web is working against it.

amanzi 5y ago

In my experience, SSO usually means "same sign on", meaning you get to use the same credentials across many different services. That'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.

evouga 5y ago

I feel like authentication these days has veered way too much towards the extreme of security over usability. My primary email account, bank accounts, medical records, etc. absolutely should be protected with MFA (and ironically often are not). 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've been repeatedly asked to regenerate? 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'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's authentication patterns.

jiveturkey 5y ago

Oh lord no. He'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.

cletus 5y ago

Weird timing. I was just dealing with an issue related to this. 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's page. Why? I guessed I'd signed on to my corp Google account on my phone at some point and it remembered. Googling didn'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. This is a terrible user experience. But even when you are signed in to more than one account it's terrible. You get a link to a Google doc, click on it and it says "you don't have permission". 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 "Request Access" and are confused why it doesn't work. I haven't experienced the author's issue of 43 sign-ons a day. Sounds like a bad enterprise setup. I'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's terrible. More often than not I find myself segragating Google accounts by browser (or browser profile). That's a pretty clear sign the product experience, well, sucks.

ElFitz 5y ago
I just hate it when clients / employers try to get me to use a Google account. If not careful, set it up once, in one place (ie email), and you’ll get logged into that account for every single Google app on your iPhone. No, Google, I don’t want to use Google Maps with some random account some client set up for me. I just want to get their emails. Nothing more. Then, of course, there’s trying to join a Google Meet meeting, and having to play around with the Google account selection. But the funniest was when I had my own GSuite org, with almost every service turned off. I’d get redirected to the admin panel, but then switching to the client’s org’s account would redirect to their admin panel, to which I didn’t have access. And getting back to the initial app (drive or meet), would bring me back into the account linked to my org, thus the admin panel… After a couple times, I ended up systematically opening those links in a private browsing window.

throw7 5y ago

"Why Single Sign on Sucks?" Because it's not kerberos. I just saw fedora 35's installation and it actually wants your login from either google/something else/etc (calling "enterprise login")... they actually hid the way to make a local account. smh. what a failure.

nichochar 5y ago

I think this experience can be significantly improved by using the w3c distributed identity[1] + verifiable credentials[2] mechanisms. 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. [1]https://w3c.github.io/did-core/ https://w3c.github.io/did-core/ [2]https://www.w3.org/TR/vc-data-model/#what-is-a-verifiable-credential https://www.w3.org/TR/vc-data-model/#what-is-a-verifiable-cr...

pabs3 5y ago

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

Danielle69 5y ago

[dead]

minroot 5y ago

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

perryizgr8 5y ago

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

xg15 5y ago

Reminds me of the "create an account or login with Facebook/Google/etc" UX you see on many sites. The promise was that services could outsource their account management to e.g. Facebook, users wouldn't have to deal with dozens of accounts and Facebook gets some more juicy user data to analyse. Win-win-win, right? Except of course sites don't want 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. However, what sites would like very much is to have their user accounts associated with a Facebook or Google identity. So what happens in the end is that the buttons really mean "login with Facebook and create an account" - which means for UX and privacy of users, it's the worst of both worlds combined.

penguinista 5y ago

Very interesting article.