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…
Why Single Sign on Sucks
61–70 of 124 posts
Re: Why Single Sign on Sucks
#62The 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…
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
#63My 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.
Re: Why Single Sign on Sucks
#64My 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 can use it from my computer too, which is a side benefit.
Re: Why Single Sign on Sucks
#65Re: Why Single Sign on Sucks
#66Maybe 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…
Re: Why Single Sign on Sucks
#67Re: Why Single Sign on Sucks
#68I 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.
Re: Why Single Sign on Sucks
#69This 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.
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
#70Earlier 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.
The problem are sites or services, that do use their own variations instead of standard.