Auth
Passkey-first authentication, Google OIDC, sessions, and the bootstrap admin email.
telark's auth surface is owned by the auth-service. It ships WebAuthn passkeys as the default credential, Google OIDC as an opt-in single-sign-on path, and Redis-backed sessions on top.
This page covers the full auth flow as the dashboard exercises it.
Passkey registration
The auth-service exposes a two-step WebAuthn registration:
POST /auth/passkey/register/start
POST /auth/passkey/register/finishregister/start resolves the user, builds the WebAuthn user
record from (id, username, fullname), and returns a
PublicKeyCredentialCreationOptions challenge. The dashboard's
features/auth/utils/webauthn helpers consume the challenge,
prompt the platform authenticator, and post the signed response to
register/finish. On success the auth-service persists the new
UserPasskey custom resource.
Re-registration is rejected with a 401 if the user already has
passkeys — the dashboard surfaces an
ErrUserAlreadyHasPasskeysPleaseLoginFirst and asks the user to
log in first.
Passkey login
POST /auth/passkey/login/start
POST /auth/passkey/login/finishlogin/start validates the email, loads the user's passkeys,
converts them to WebAuthn credentials, and returns an assertion
challenge. login/finish verifies the signed response,
persists the new session, and returns it.
auth-service records device metadata (DeviceMetadata) parsed
from the login request body so the dashboard can show a per-device
list under Settings → Security → Passkeys.
Sessions
Sessions are UUID-tokened with a configurable expiry — 24 hours by default. The expiry, idle timeout, and cleanup interval live in the auth-service config and can be overridden by environment variables on the auth deployment.
The auth-service runs a cleanup controller
(controllers/cleanup) that periodically drops expired sessions
from Redis. Manual logout is DELETE /auth/session — it
invalidates the current session token immediately.
OIDC: Google
telark supports Google OIDC as a secondary sign-in path when
globalconfig.spec.oidc.enabled is true and googleClientID
is configured.
GET /auth/oidc/google/start
GET /auth/oidc/google/callbackgoogle/start issues a state nonce, persists it briefly, and
redirects the browser to Google. google/callback validates the
state nonce, exchanges the authorization code for an ID token,
verifies the email is verified, resolves or provisions the
UserAsResource for the email, and issues a telark session.
If oidc.enabled is false or googleClientID is empty, the
callback responds with the configured error and the dashboard hides
the Sign in with Google button.
Bootstrap admin
First-time install needs a way to grant the first admin. The auth-service reads a bootstrap admin email from configuration (typically set as a Helm value) and grants the Admin role to the first user whose login email matches that value. After bootstrap, the field is ignored — additional admins are added by assigning the Admin role via the dashboard.
Authorisation surface
/auth/authorisation/permissions returns the permission set the
current session resolves to. The dashboard caches this and uses it
to gate UI elements (the Create group, Trigger rollback,
Cancel plan buttons all hide or disable when the relevant
permission is missing).
Where it lives in the UI
The dashboard auth feature
(dashboard-ui/src/features/auth/) covers:
- A login page with email + passkey, with the Sign in with Google button gated by the OIDC config.
- A register page for first-time passkey enrolment.
- A passkey manager under Settings → Security → Passkeys showing every registered authenticator, the device metadata, the registration time, and a Remove action.
- A Terminal demo component on the login page that shows what the passkey flow looks like as a curl-ish exchange.