We know we keep getting feedback that people want a different way to authorize their accounts (especially for personal use), so we're looking at other options. We just really want to stay out of the username+password business; it's simply bad security practice.
And you don't get any key rotation unless you force people to change their passwords occasionally, which is itself now deprecated as a bad practice because people then start writing their passwords down on paper or storing them in a spreadsheet, which is even worse than no rotation. (Tailscale rotates your VPN keys automatically, but it's all for naught if the root key is just a password.)
We know that something better is needed for personal accounts, but please, not username+password. Your private network security is important. The world needs something much closer to foolproof.
I'd be very surprised if this was true. Most all technical (competent) people I know use a pw manager of some sort
Unfortunately non-technical people mostly don't use a password manager and we can't assume they do. Tailscale is about making the Internet secure by default, and passwords will never be secure by default.
FWIW, we'll probably also be supporting GitHub (and maybe Twitter?) auth, as well as perhaps letting you run your own auth server if you set up the right DNS records. Lot of things yet to do.
On the other hand, I really like Keybase's way of federating multiple identities together, where each additional identity provider increases rather than decreases confidence.
If your highest concept of identity is the account and identity managers allow you to authenticate to that account, let's say you have a tailscale account with id 123, and any human who has access to john@personal.org or john.smith@job.com can access that account.
What do you do when John leaves job.com? Can John (accessing the account through john@personal.org) still admin the job.com bits?
I think the right abstraction is having first-party (in this case tailscale) accounts belonging to one or more "teams" and authenticating with a @job.com address allows you to switch to the job.com team in the UI / allows you to generate API creds that modify job.com's team.
Sign in with Apple works natively on iOS, macOS, tvOS, and watchOS. And it works in any browser, which means you can deploy it on your website and in versions of your apps running on other platforms.
So it at least sounds like it can be used anywhere with a web login flow. Although the docs say this must be accomplished using their JS library, as opposed to a standard OAuth2 flow of some kind: https://developer.apple.com/documentation/sign_in_with_apple
I really want to give you guys money for my personal use but $10/user/month is steep when I know the other users will only use it once it a blue moon (but of course, when they need it they'll REALLY need it).
If there was something like a "supporter plan" that was similar if not identical to the free plan but charged a flat fee, I'd be all over that.
In the meantime, it's fine to be on the solo plan for personal use, it's there and free to be used :)
Personally I want ZT to integrate support for integrated (e.g. Apple security chip) and discrete (YubiKey etc.) secure tokens and enclaves. That is where the real security is at.