Learn Tailscale - Authentication & SSO

#Introduction

In episode 12 you understood the encryption layer. But before encryption speaks, there's a question that must be answered: who are the devices and who are the people joining the tailnet? This is the identity layer — and the answer comes from authentication and SSO.

Episode 13 covers how a tailnet verifies identity: logging in via Google, GitHub, Microsoft, or Okta with multi-factor authentication, using auth keys for automated provisioning without human interaction, API keys for integration, and Tailnet Lock to protect the tailnet even if an admin is compromised.

#Identity Authentication

#SSO at the Gate

The first time you run tailscale up, you're directed to the login page of your chosen provider — this is Single Sign-On (SSO). Human identity comes from a corporate or personal identity provider, not from Tailscale's own database:

• Google: personal accounts or Google Workspace.
• GitHub: developer accounts.
• Microsoft: Microsoft accounts and Entra ID.
• Okta: the enterprise platform for large organizations.

tailscale login

The tailscale login command re-opens the authentication flow, useful when you want to switch providers or reconnect an expired node.

#Multi-Factor Authentication

MFA happens at the identity provider level: if your Google or Okta has MFA enabled, Tailscale login uses it automatically. That means one extra security layer with no additional configuration in the tailnet. For organizations, enforce MFA in the provider policy to protect tailnet access from compromised accounts.

#Keys and Tokens

#Auth Keys for Automated Provisioning

For cloud servers, containers, and headless devices, there's no browser to log in with. The solution is auth keys — single-use keys generated in the admin console:

sudo tailscale up --auth-key=tskey-auth-kEYmPLdExample

Auth keys can be one-shot (used up once) or ephemeral (node automatically removed when it goes down). The sudo tailscale up --auth-key=... command enables provisioning without human interaction — an important pattern for episodes 17 and 21.

#API Keys for Integration

An API key is used to call the Tailscale API — managing devices, ACLs, and configuration from code. The difference from an auth key: an API key is an admin credential for the API, not for node login:

curl -s https://api.tailscale.com/api/v2/tailnet/example.com/devices \
  -H "Authorization: Bearer tskey-api-xxxxx"

The curl -s ... -H "Authorization: Bearer ..." command retrieves the device list via the API. API keys must be stored securely and given a validity period — never commit them to a repository.

#Tailnet Lock: Hardware Keys

Tailnet Lock adds signature approval: significant tailnet changes — like adding a new node — require signatures from a designated set of keys. Even if admin credentials are hacked, an attacker still can't add nodes without keys meeting the threshold:

sudo tailscale lock init
sudo tailscale lock sign

The sudo tailscale lock init command enables the lock and shows your key. tailscale lock sign signs pending operations. Tailnet Lock is a strong last line of defense for production tailnets.

#Healthy Authentication Practices

#Identity Layer Checklist

• Enable MFA at the identity provider.
• Use one-shot or ephemeral auth keys for provisioning.
• Limit the validity period of auth keys and API keys.
• Enable Tailnet Lock for tailnets with many admins.
• Monitor login logs and devices in the admin console.

Humans   -> SSO (Google/GitHub/Microsoft/Okta) + MFA
Devices  -> auth keys (one-shot/ephemeral)
Integration -> API keys / OAuth
Defense  -> Tailnet Lock (signature approval)

#The Correct Authentication Flow

#A Proven Provisioning Sequence

1. Create a one-shot auth key with a short validity period
2. Provision the node with the auth key
3. Verify the node appears in the admin console
4. Manual SSO login for workstations
5. Rotate the auth key after provisioning is done

This sequence ensures no auth key sits idle for too long. For workstations, let the SSO flow run — human interaction actually ensures device ownership is identifiable.

#Authentication Is a Process, Not a Status

Tailnet identity isn't something configured once and forgotten. Key expiry forces nodes to re-authenticate periodically, and Tailnet Lock keeps changes controlled. Treating identity as an ongoing process is the key to long-term security.

#Summary

Authentication is the gate that keeps the encryption layer meaningful. With SSO plus MFA for humans, auth keys for automated devices, API keys for integration, and Tailnet Lock as a safety net, your tailnet has a complete identity layer.

#Closing

Episode 13 completed the first layer of the security model: identity. You understand the SSO and MFA flow, provisioning with auth keys, API key integration, and the extra protection of Tailnet Lock.

Key takeaways:

• Human identity comes from SSO: Google, GitHub, Microsoft, or Okta.
• MFA automatically follows the identity provider's policy.
• Auth keys enable provisioning without a browser.
• API keys are credentials for managing the tailnet via the API.
• Tailnet Lock requires signature approval for major changes.
• The identity layer is the gate before encryption speaks.

In the next episode, episode 14, we'll cover security hardening and advanced ACLs — granular per-node and per-user ACL rules, tag-based policies with least privilege, plus a hardening checklist like key expiry, device monitoring, Taildrop and SSH restrictions, and securing public server nodes.