Live data from Hacker News

Why Single Sign on Sucks

goteleport.com

61–70 of 124 posts

Re: Why Single Sign on Sucks

#61
post #58

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 (a…

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.

Re: Why Single Sign on Sucks

#62
post #54

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 t…

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.

Re: Why Single Sign on Sucks

#63

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.

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.

Re: Why Single Sign on Sucks

#64

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.

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

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.

Re: Why Single Sign on Sucks

#65
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.

Re: Why Single Sign on Sucks

#66

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…

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.

Re: Why Single Sign on Sucks

#68

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.

Not just miss the point but isn't also just incorrect? SSO typically doesn't require you to login more than once a day. Unless they explicitly set a policy to expire sessions really fast. If you have Okta/Auth0 or the like in your enterprise it should cookie your session in the identity provider and automatically admit you to anything gated by that identity provider

Re: Why Single Sign on Sucks

#69
post #32

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.

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.

Re: Why Single Sign on Sucks

#70
post #57

Earlier quoted context omitted.

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

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.

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.

Post reply on HN