Authentication and Users

Authentication and Users

TinyIce has two distinct authentication surfaces:

1. Admin / management — humans and scripts that manage the server. Session cookies (web UI), passkeys, OIDC, or bearer tokens.
2. Source ingest — encoders publishing to a mount. Per-mount source passwords (Basic Auth), covered in Streaming Sources.

This page covers the first.

Roles

Three roles, least-privilege by default:

Role	Can
superadmin	Everything, including transcoder/webhook/AutoDJ CRUD and user management.
admin	Day-to-day operations: streams, relays, kick, bans, lockout clearing.
dj	Scoped control of granted mounts (e.g. AutoDJ playback), no server-wide config.

Some actions are explicitly gated to superadmin because they let a user run shell commands as the service account — notably AutoDJ create/update/delete (arbitrary song_command / on_play_command) and webhook CRUD. See Security for the rationale.

The first run bootstraps a superadmin (admin_user / admin_password); on load it's migrated into the unified users map.

Users

A User carries username, bcrypt password hash, role, per-mount grants (mounts), enrolled passkeys, and linked OIDC emails. Manage in Admin → Users.

• Login is constant-time. Bcrypt (cost 12) runs even for unknown usernames, against a dummy hash, to close the account-enumeration timing oracle (~250 ms either way).
• Sessions have an absolute 7-day and sliding 24-hour expiry, reaped periodically. Login rotates the session cookie (no fixation). Deleting a user immediately purges their live sessions.

Passkeys (WebAuthn)

Passwordless login with platform or roaming authenticators. Configure the relying party under webauthn:

"webauthn": {
    "rp_id": "radio.example.com",
    "rp_name": "My Radio",
    "rp_origins": ["https://radio.example.com"]
}

rp_id must match the registrable domain; rp_origins must list the exact origin(s) the admin UI is served from. Enrol passkeys per user in Admin → Users.

OIDC / OAuth2

Log in via GitHub/Google/any OIDC provider. Configure under oidc_providers (client_id, client_secret, discovery_url, icon, enabled).

Hardening built in:

• OAuth state is bound to the originating browser; nonce is set and the ID token is verified.
• email_verified is required. For GitHub, /user/emails is consulted and only primary + verified addresses are accepted.
• New OIDC sign-ups land in pending_users and must be approved by an admin before they get an account (Admin → Pending Users). Approve/deny are CSRF-checked.

Bearer API tokens

For scripts, CI, and integrations. Create in Admin → API Tokens; the plaintext token (ti_…) is shown once and only its hash is stored. Tokens carry a role, optional expiry, and last-used IP/time tracking.

curl -H "Authorization: Bearer ti_your_token_here" \
  http://localhost:8000/api/streams

Use tokens — not your admin password — for automation. See HTTP API.

Email notifications (SMTP)

Optional outbound email under smtp (host, port, from, username, password) for account/notification mail. Independent of Webhooks.

---

Next: Security for bans, scan protection, and the threat model · HTTP API