Skip to content
TixFin

Security

Security that is not an afterthought

Passkeys and TOTP, hashed recovery tokens, layered rate limits and strict ownership checks — plus structured GDPR exports for the requests you have to answer.

Get started freeAll features

In short

How does TixFin handle security?

On top of password login, the platform supports TOTP two-factor with backup codes, passkeys via WebAuthn for passwordless sign-in, and device management so active devices can be removed individually. Accounts with an unverified email address no longer receive a usable login, OAuth, passkey or email-code session; they are consistently pointed at the verification flow. Password reset, email verification and email change tokens are stored hashed server-side with strict expiry, and refresh tokens never leave HttpOnly cookies.

  • Passkeys (WebAuthn) and TOTP with backup codes

  • Hashed recovery tokens and HttpOnly refresh tokens

  • Layered rate limits with Retry-After headers

Specifications

Key facts

Second factors
TOTP with backup codes and passkeys (WebAuthn)
Default SSO lifetime
Configurable Keycloak SSO session lifetime (365 days by default), with access cookies tied to real token lifetime
Token storage
Recovery and verification tokens hashed server-side; refresh tokens HttpOnly only
Rate limiting
Per IP, identifier and target object, with 429, Retry-After and RateLimit-* headers
GDPR export
Self-service and admin export covering account, tickets, invoices, memberships and support

Capabilities

Defence in depth

  • 01

    Strong authentication

    TOTP two-factor with backup codes, passkeys via WebAuthn for passwordless login, and device management to revoke individual devices.

  • 02

    Verification enforced

    New and existing accounts with an unverified email get no usable login, OAuth, passkey or email-code session, and are pointed at the verification flow instead.

  • 03

    Token hygiene

    Reset, verification and email-change tokens are stored hashed and time-limited; access tokens live only transiently in session storage, never in local storage.

  • 04

    Anti-abuse layer

    Login, registration, invitation registration, password and email-code flows, public shop mutations, guest checkout, support chat and proxy access are limited per IP, identifier and repetition, with 429, Retry-After and RateLimit-* headers surfaced to the frontends.

  • 05

    Ownership hardening

    Public and authenticated endpoints check object context and ownership before reading, changing or deleting, and public responses no longer expose internal user or ownership IDs.

  • 06

    GDPR exports

    Self-service export for a user's own account and an admin export for support and compliance, bundling account, security, ticket, invoice, notification, membership, support and waitlist data without exposing secrets in clear text.

How it works

Hardening an account

  1. 01

    Verify the email

    Verification is required before a session becomes usable, on every sign-in path.

  2. 02

    Add a second factor

    Enable TOTP with backup codes, or register a passkey for passwordless sign-in.

  3. 03

    Manage devices

    Review active devices and remove any that should no longer have access.

  4. 04

    Export on request

    Provide a structured data export through self-service, or through the admin export for a formal request.

Security

Secure defaults, not optional extras

Production refuses to start without a separate strong OAuth state secret and mandatory email verification, requires HTTPS and secure origins for frontend, WebAuthn and OIDC, and expects Docker secrets for central backend secrets. Structured security logs and metrics record auth attempts, 4xx/5xx and 429 series and unusual access patterns per IP.

Use cases

Built for

FAQ

Security questions

Ask the team

  • Yes. Passkeys via WebAuthn are supported alongside password login and TOTP two-factor with backup codes, and device management lets active devices be removed individually.

  • Login, registration, invitation registration, password and email-code flows, public shop mutations, guest checkout, support chat and proxy access are rate limited per IP, identifier and repetition, and 429, Retry-After and RateLimit-* headers are passed through to the frontends.

  • Yes. A self-service export covers a user's own account, and an admin export supports compliance and information requests. Both bundle account, security, ticket, invoice, notification, membership, support and waitlist data, and security-critical secrets are never delivered in clear text.

  • Public and authenticated endpoints verify object context and ownership before data is read, changed or deleted. Seat reservations enforce ownership checks on release and scope and permission checks on confirmation, and logged-in users see only their own reservations without elevated rights.

Start on secure defaults

Set up your project with passkeys, two-factor and verified accounts from day one.