Why Single Sign on Sucks
goteleport.comGitHub'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.
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.
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.
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.
This is a frustrating limitation of GitHub’s setup and is hard to find out who people are. As an admin, I can theoretically search the org membership for HugeDick53 and see that it’s associated with John.smith@example.com, b it regular users in the org are at a loss.
We have a loose convention that everyone update their profile with their name. But this is visible publicly, so if an employee doesn’t want their name public they are hosed.
I wish there was an option for an “enterprise” account that would stay hidden to everyone except org members.
But I do applaud GitHub for sticking with the idea that dev identities belong to individuals, not their orgs. So when someone leaves a company they can keep their profile.
I use a single GitHub account with activity for years and link and unlink it to orgs as necessary. Since I also do dev work, I worry that if someone compromises my account or gets a token, they will be able to wreak havoc on multiple orgs and repos where I have access.
> I wish there was an option for an “enterprise” account that would stay hidden to everyone except org members
There is: Take a look at Enterprise Managed Users https://docs.github.com/en/enterprise-cloud@latest/admin/ide...
We used to use terraform to invite people to our github org, along with a file in a repo to map company emails to github usernames. When a new starter joins, their manager submits a PR to add their username.
It was a huge mess - it would fail to apply if you looked at it funny, and it had no controls against someone typo-ing a username and inviting a random person to the org. But it solved this case at least.
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.
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.
I see this in situations similar to sudo where you need to make sure it is the same user that signed on when elevating privileges, vs letting in anyone who sits down at an unlocked user's terminal.
If I had to wait for several hundred network requests to complete and one or two pages to render every time I sudo'ed I'd complain about that too.
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.
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!”
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.
I would say that's not really a SSO issue so much as it's an obnoxious session duration policy.
Honestly I don't mind this too much as long as it's yubikey only, that literally is just reach up, tap, hit enter: 1-2 seconds if you know it's coming. If they require to reenter a password it's more like 10-30 seconds depending on if I mistype anything. That's just setting the wrong incentive to have a weak password that is easy to type.
Same here. If anyone has different experience you should file a bug on your IT department.
The example from the article looks terrible and should not be seen as representative for how SSO can work.
That said, it’s still not the sign on nirvana we all want to have, browsers and OS still have a lot of areas for improvement here.
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.
I can think of two times in my life where I even considered the possibility that one of my peers would do something malicious on their way out the door, but management worries about this all the time.
On the one hand, Precautionary Principle. The costs of being wrong - and having to explain it to the Board - are just unimaginable. So sure, if you want IT to have a way to push a button and block someone out of the entire network in the time between when their boss says, "Hey, can we talk" and the office door goes 'click', then centralized credentials at least can be somewhat atomic. Session caching, to make this arrangement perform, undermines that immediately of course.
On the other hand, when someone accuses you of something way, way out of character, we learn as we mature that it's fairly likely this person did some mental arithmetic that went, "What would I do in this situation?" and that popped out. The person who accuses you of stealing their mug at the drop of a hat may have a passing fancy with stealing mugs themselves.
So we learn that in perhaps 95% of cases, non-sequitur suspicions are either the product of the mind of a suspicious person, of someone who is jaded by bad experiences (steal someone's lunch enough times and they will start accusing random people), or of someone who deep down knows they kind of deserve whatever is about to happen.
So it troubles me a bit how quickly the C Suite prioritizes having a giant switch to lock people out.
I've developed a nervous habit of any time I hear someone getting 'talked to for a second' or suddenly a bunch of 1:1s show up, of cleaning up my computer a little bit, then my desk. Rarely do I have anything that is worthy of cleaning up, but it doesn't hurt and gives me somewhere to put some of that feeling of impending doom. If I had a bad experience of having to clean out a messy desk, I don't remember it very well, but I'm sure it's happened. I know the first time I quit I learned not to try to take everything home on the last day. Somehow my stuff always ends up being bulkier than I estimate.
> I can think of two times in my life where I even considered the possibility that one of my peers would do something malicious on their way out the door, but management worries about this all the time.
Because employers see how some employees act as they depart, even though they don't act similarly around their coworkers. Employers also see trusted employees smile and leave for competitors even after signing that they would not do that. Employers are right to suspect departing employees, because some steal information or otherwise cause issues before they leave.
> So it troubles me a bit how quickly the C Suite prioritizes having a giant switch to lock people out.
I've seen dozens of systems that had to be accounted for when an employee left. Almost all of those systems required separate action to remove the departing employee, plus follow-up checks that sometimes had to be from humans.
It only makes sense to have your employee separation procedure get automated, and during automation it makes sense to communicate with one system instead of communicating with 30 systems that each respond in different ways - some of which require human intervention.
> Employers also see trusted employees smile and leave for competitors even after signing that they would not do that.
Employers who ask their employees to sign immoral and usually illegal non-compete clauses deserve whatever they get, honestly. Employers should expect their employees to go work for competitors when they leave. Where else are they going to go work, but companies with similar operations? An ecology management company fires and ecologist and they clutch their pearls when that ecologist goes and works for another ecology management company, instead of McDonalds!? Gasp! The nerve of that person!
Don't want your employees to go work for a competitor? Don't treat them like shit.
> Employers who ask their employees to sign immoral and usually illegal non-compete clauses deserve whatever they get, honestly. Employers should expect their employees to go work for competitors when they leave.
That's my point as to why employers want to immediately stop access to employees who leave for competitors.
> An ecology management company fires and ecologist and they clutch their pearls when that ecologist goes and works for another ecology management company, instead of McDonalds!?
You can word it that way, but what can and does happen is that employees leave and steal confidential processes or information to boost their own value at a competitor. Many people agree with you, until they start their own company and theft happens to them, draining their work straight to a competitor.
If that was the goal, wouldn't you do that in advance anyway before any suggestion you were bailing?
Sure, but it doesn't always happen like that.
You're in sales at a company in a highly competitive space and are exited. You're not the kind of person to premeditate taking anything with you, perhaps you left on good terms. You join another company and someone there asks you for the book of business or sales leads you were working on that the previous company. Oh look, your login to the CRM system is still working, and you can get a glimpse of information that you shouldn't have access to as a non-FTE. It seems benign, so you copy down a few phone numbers and email addresses. This isn't an academic example.
This wouldn't even be a possibility if the account was locked down immediately. It's obviously much more difficult to control access to information while you are employed (this is a subplot of Snowcrash, afterall), but immediate lockout isn't meant to mitigate that risk. It's meant to mitigate risks from an account being active that shouldn't be.
Absolutely not only is immediately removing the terminated employee’s access critical but setting up SSO and auto-provisioning/de-provisioning so straightforward and effortless with many SSO products that it’s essentially malpractice to not do so.
> You can word it that way, but what can and does happen is that employees leave and steal confidential processes or information to boost their own value at a competitor.
I mean, couldn't you make an argument where that's just capitalism at work? If Firm A is going to be competitive, they'll need to compensate their employees well enough that Firm B doesn't have the ability to poach. An employee with a considerable amount of stock in Firm A is gonna think twice before they devalue their shares by running to a competitor.
> Many people agree with you, until they start their own company and theft happens to them, draining their work straight to a competitor.
Again: tough luck.
> Because employers see how some employees act as they depart, even though they don't act similarly around their coworkers
It's fun, because in my experience, departing employees are always playing ball, while employer starts doing stupid things.
In France, we have 3 months (!) of resignation notice (and it usually really lasts 2). I've always seen departing colleagues still working the whole notice. However managers start asking stupid things "please prepare demo for this prospect, it should take you one month and a half, so 2 weeks to spare!", "hey we need this feature, you're the only one who can do it, please code it before you leave", but rarely "write documentation for everything you did".
> Employers also see trusted employees smile and leave for competitors even after signing that they would not do that.
What? Such clauses actually exist and are actually used?
In France, such a clause requires (ex)employer to pay at least 50% of salary during the period where the (ex)employee isn't allowed to work for competitors (I can't see how this can be a fair agreement without that compensation), but companies pretty much never enact those clauses, because well, they don't care about employees going to the competition /that/ much
> What? Such clauses actually exist and are actually used?
Unfortunately it's pretty common in the US, though in some states (like California) such clauses are illegal and unenforceable.
I'm always torn on these sorts of labor requirements/protections. I think anti-compete agreements are gross, but I also wouldn't want to be subject to a mandatory notice period of any kind, let alone 3 months.
I can think of two times in my life where I even considered the possibility that one of my peers would do something malicious on their way out the door, but management worries about this all the time.
Proper offboarding protects you too, not just the company. If you leave the company and someone compromises one of the 27 hard-coded credentials left behind on various machines and services, then it puts you under suspicion.
In companies where I do have hard coded creds (including shared passwords), when leaving a company, I compile a list of all of them and send it to my manager and tell them to make sure they are all disabled.
Yep. It's like sharing passwords to important personal accounts more generally. Sure, the main reason you don't is that stuff can happen in relationships and people can end up doing things you didn't think they would. But a secondary reason that if something does happen in an account that you've shared a password with someone, it's hard not to have at least a glimmer of suspicion.
Ignoring the "actual security" angle for a minute.
When you have thousands of accounts and dozens to hundreds of services, manual management just stops being practical.
Most large orgs are subject to one form of compliance or another, and it's inevitable that at some point you have to prove to an auditor that you have onboarding / offboarding processes for everything as that's in their checklist.
This is difficult to prove "at scale" and removing tons of per-service UAR processes is the main value. Each service is an opportunity to screw up - forget to document the process, forget to execute the process, (my favourite) forget to record that you executed the process, or execute the process wrong.
The alternative to automation in a big company is that accounts get left dormant for years.
You're overly focused on individual behavior of ex-employees, and overestimating the amount of thought the C Suite is putting into the matter.
The risk does not come primarily from disgruntled employees doing bad things—there's already a huge legal deterrent to that since they know exactly who you are. The bigger risk is what can happen when credentials are stolen by actual criminals. This is context dependent, but scales with the number of employees times the number of accounts, the latter of which has trended up dramatically as cheap B2B SaaS has proliferated.
What happens when a laptop is lost? What happens if a DB is hacked and users had reused passwords? How do we know who even has access to what when teams self-administer access control? These start to become real security problems at relatively modest scale even if we assume every employee is a saint.
Even leaving security aside, the management of accounts starts to become a significant pain point in the low hundreds of employees and so it will typically be the IT team that pushes for SSO first well before compliance comes into the picture.
As the de-facto Security team - the main concern for me isn't so much "lock everyone out immediately" aspect, it's the reduction in the number of sets of credentials for people. It is a benefit in the onboarding/offboarding process, too - it's one less thing you need to go in and manually turn off accounts.
People suck at remembering passwords, and even if you go and give them Password Manager tools like 1Password/Lastpass/whatever, they'll still tend to re-use the same password they use for their personal email, and that random service that recently got pwned.
It's worse when they have credentials like AWS IAM Keys that are while not difficult, are inconvenient to rotate. Those are likely to just sit around on someone's machine and get leaked inadvertently in logs or test code.
It’s just bad practice having accounts scattered through bunches of systems that shouldn’t be used anymore.
It’s often a licensing issue, and definitely a security issue.
Either you maintain this manually - proper time consuming chore at larger companies with many systems and applications.
Or write automations to manage it. Better, but still a lot of work and not always technically possible.
Or you hook as many of these systems as possible up to an SSO solution backed by some kind of identity provider.
This grants many benefits for everyone during the lifecycle of systems and its users - sysadmins, it-support, infosec but perhaps most of all the end-users.
As a manager myself I first and foremost think about how the on-boarding works: is it smooth, and are new hires gaining access to the systems they need without 15 calls to the service desk.
Hah. If you worry about malicious employees I can tell you that SSO is the opposite of a solution.
Most SSO integrations have very bad Single-Sign-Out design, if any at all. So as long as the token in your session has not expired yet, you have full access to resources, even if account is blocked in the Id Provider.
ignoring all of this, the fact that you can use SSO and then people will have access to most services without having to login to most of these services (loads of services have "anyone in this G Suite org can get into your account") is a godsend.
No more chasing around for each service figuring out who is the admin for what.
No, SSO also helps me. Having only one password to change is really nice. It’s the SSO process that annoys me. Between all the redirects and duplicate information, signin takes 4 times longer than user/password auth.
My company's single-sign-on got upgraded with mandatory 2FA a couple years back, and somehow requires it every time. It's really more of a non-stop-sign-on, I probably do it 10 times on any given day (including waiting for the SMS, etc, I wonder how much this one poorly-configured service costs them).
It would also help an adversary that only needs to know your one password.
Which is why we also use 2FA. You are using 2FA right?
Implying 2FA is bulletproof? I use separate 2FA and passwords for everything.
I don’t think the OP implied that 2FA is bulletproof…
I also don't think that the client certificate solution that is trumpeted at the end (for which I don't blame them, content marketing has to content market) is a great option. From the post:
"The UX and tech for PKI Infrastructure isn’t great, and the client UX sucks."
Guess what, it has for years and years. Deployment is hard. Creating certs at scale for normal users has been available for a long long time, but no one has done that.
I think that a more fruitful approach would be to go the webauthn path, and tie into the browser/OS for support (as mentioned in the article). Boom, deployment solved (https://caniuse.com/?search=webauthn has the list; it's most major browsers on mobile and desktop--the only one missing that I'd love to see add it is FireFox on Android).
Now you need to tie into the application and I don't want to diminish that effort. But many apps use libraries or auth servers, so your surface area for deployment is far smaller.
Having persisted with user authentication X509 for years, I can in fact tell you the UX got _worse_ over time. We wound up sometimes making key pairs and certificates for end users and emailing them because browser enrollment is so shonky.
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
My former employer set expiration at 3 hours. It was super annoying.
Yes. I sign on by typing my email address and then... redirect... redirect... signed in. Guess the interface could be nicer but generally it's nice
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.
Single Sign On works beautifully in the Windows environment. Logon to one workstation, access any server's file or print shares, SQL server, IIS websites, and tons of third party software without any logon prompts but still with granular permissions.
One of those things people who say "I don't understand why anyone uses Windows" don't understand. Something so pervasive and convenient that "we" the industry have given up in moving everything to the web, along with standard menus, ubiquitous keyboard accelerators for menus and dialog boxes, scripting with the likes of COM, ActiveX, AppleScript, or embedded Python/Lua, local snapshots or volume shadow copy, tools like DNSpy and AutoHotkey and SysExporter able to introspect into running programs and their windows and system controls (and they generally weren't obfuscated javascript inside), being able to see different programs in task switchers without them all being wrapped in a web browser.
It was a different and in many ways better world 10-15 years 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.
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.
for the benefit of others (I had to search it): https://www.linkedin.com/pulse/difference-between-system-rec...
Yeah, the manifestation of "LDAP Integrated" still means you have to sign into every single service, it just uses the same credentials.
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.
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.
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.
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.
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?
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.
> 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.
That's not true. nginx, for example, let's you return a custom response, which can easily be a 302 to the login page.
But I agree with all other points. On a sidenote, there's also the great option of using a CA for your client certificates while still using a normal CA for your https certificate - you don't have the worry of installing a root certificate on all clients and still have a nice, valid https connection in the browser. Unfortunately, hardly any tutorials pointed this out and used their own CA for everything instead.
> Unfortunately, hardly any tutorials pointed this out and used their own CA for everything instead.
I think this is one of the reasons so few people consider using TLS auth. There aren't many guides out there, and many of the ones that are easily accessible use a custom CA deployment that's an absolute pain to manage (custom TLS certs on websites with a custom ACME server or manual certificate generation, and so on).
Sometimes I feel like writing my own guide, but I'm not 100% confident that I'd get everything right.
I’ve been in this boat and have documented weird bugs and things that don’t work, but yet to write something about a working configuration.
I wanted to use mTLS for self hosted services and it took a while to come up with something that worked well in browsers, but apps on iOS and Android basically can’t use the certs making it fruitless.
I’ve used client certs for maybe 25 years. They are hard to configure. Most devs can’t get them working.
They also used to be expensive but I expect that’s dropped.
I’ve seen many “client certificate” solutions over the year that end up trying to do client management and crap out in many situations that are hard to fix (eg, user changes their environment and the cert is gone, now they can’t log in).
To make it easy enough to use, it ends up having all the flaws of our current sso environment. My friend had a company he was trying to start where he would automatically create and revoke client certificates for every device and session. But they were so ephemeral, they may as well have been cookies and it ended up being really cumbersome to try to keep track of certs on client devices.
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.
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.
Oh, I didn't make it to the bottom of the article lol, I see that is what this is about.... cool!
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.
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).
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.
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.
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 "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.
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.
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.
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)
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.
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?
(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.
We certainly agree on the importance of making it easy and convenient for the users to behave well. The traditional example here is onerous password requirements that lead to post-it notes.
> 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.
This is a great point that I hadn't considered. Thank you!
I was describing SSO logins.
Ahh! So saml2aws is authenticating to the same IdP to which you are authenticating in the browser in the first paragraph?
Sorry, I thought you were trying to gain convenience by simulating SSO.
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.
SSO sucks nothing in compare with TOTP-incompatible "please scan QR" mobile auth. With uniq app per service.
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.
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.
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"..
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).
> 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.
The risk of course being that if your password manager gets hacked then they get the keys to everything. I've been wondering about whether it might make sense to use two separate password managers: one for password, one for TOTP. It's almost as convenient, and it's extremely unlikely that an attacker can compromise both independent password managers at once.
What do you get out of having a GitHub app on your phone? I've never needed or wanted to think about pushing code from my phone. Things I may want to know about are already emails I can reply to (or the mobile website if an emergency).
> 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.
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.
"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.
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.
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.
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!
Don't get me started...
> 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).
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/
[2]https://www.w3.org/TR/vc-data-model/#what-is-a-verifiable-cr...
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.
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.
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.
This doesn’t work for push based auth, unsure if they support Totp fallback though
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.
> 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.
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.
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.
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.
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 "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
Why don't people just use webauthn?
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
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
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.
This is incredibly naive, you have to consider support of both applications and help desks, and the cost of those.
Very interesting article.