Why Single Sign on Sucks
goteleport.com
goteleport.com
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.
Note that Github only allows one free account, so the business needs to pay for each one if its dev accounts.
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.
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.
There is: Take a look at Enterprise Managed Users https://docs.github.com/en/enterprise-cloud@latest/admin/ide...
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.
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.
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.
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.
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.
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.
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 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.
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.
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.
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.
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
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.
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 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.
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.
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.
No more chasing around for each service figuring out who is the admin for what.
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.
"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.
Also the examples they mention are all just badly configured applications, which can easily be fixed.
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.
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.
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.
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.
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 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.
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.
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.
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).
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.
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.
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.
SSO without central identify management would be weird but also very possible.
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 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 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.
> 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!
Sorry, I thought you were trying to gain convenience by simulating SSO.
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.
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"..
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).
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.
This is no longer an issue, if you use SameSite=Strict, Secure, HttpOnly cookies.
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.
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.
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.
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!
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).
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...
The problem are sites or services, that do use their own variations instead of standard.
I can use it from my computer too, which is a side benefit.
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.
No in an ideal world, you would log into your computer, and never be bothered again.
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
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.