I edited the original to contain more detail as I posted it but it seems to have been lost somehow. The login flow for Tailscale is weird due to the need to accommodate things like a headless server being added, when combined with their use of SSO as the only method of authentication things get confused very easily.

When I add a new server I get given a URL that looks like https://login.tailscale.com/a/c44a243b to visit in a browser and authenticate the new device, the meaning of which is quickly lost as soon as you go through a Google Authenticator sign in flow, fill out some recaptchas and find your phone for a SMS token, and then the device is added to your account with no further clicks (unless you enable device authorization). It feels very weak, the connection between logging in and performing an action is fuzzy.

Due to the use of Google SSO it just has the usual problems that you get. It's not quite clear when you're logged in or not or with which of the 12 google accounts you own, it's not clear what will pop 2FA requests or login prompts. As a service tailscale has made it clear that they don't want to be an "identity provider", which means you're sort of stuck with something that doesn't feel like you can make authoritative decisions about how it acts.

SSO is not the only method of authenticating things. They have auth keys specifically for the purpose of authing headless servers. e.g. sudo tailscale up --authkey tskey-abcdef1432341818

You can also apply an ACL tag to it so that it is no longer authorized as the user and instead takes on the permissions of the tag.

In our deployments we have the headless servers pull the tagged auth key from secrets manager on boot and then just `tailscale up --authkey <value>`.

I agree the default login flow is usually not what you want for headless servers. It sort of leads you down the wrong path.

This is great -- I wish it was more plain in the admin UI that this is the better headless workflow. That seems like an easy fix!