waylog
Core Systems

Authentication

Dual authentication strategies for web and desktop clients.

Waylog operates across two entirely different environments: the browser and the desktop. To ensure security and seamless user experiences, we employ a dual-authentication strategy.

Web Platform: Better Auth

For the apps/web frontend, we rely on Better Auth, deeply integrated with our Drizzle ORM setup.

  • Configuration: Housed in packages/auth/src/index.ts.
  • Session Management: Traditional secure, HTTP-only cookies govern browser sessions.
  • Providers: We currently support standard Email/Password authentication.
  • Steam OpenID (Planned): Because Steam utilizes OpenID 2.0 rather than standard OAuth2, a custom integration is planned to facilitate secure Steam profile linking directly within the Better Auth ecosystem.

Desktop Client: Native Auth (PKCE)

Standard cookies are insufficient and insecure for a standalone desktop application. The Tauri client will utilize a Proof Key for Code Exchange (PKCE) flow to obtain long-lived access tokens.

The PKCE Workflow

  1. The desktop app generates a cryptographic code_verifier and a code_challenge.
  2. It opens the user's default browser to the Waylog web login, passing the code_challenge.
  3. Upon successful Better Auth login, the server issues a temporary, short-lived authorization code and redirects back to the desktop application via a custom deep link (waylog://auth).
  4. The desktop app sends the authorization code alongside the original code_verifier back to the server.
  5. The server validates the exchange and issues a persistent Bearer token.

Security Guarantees

  • The desktop client securely stores the raw Bearer token locally.
  • The server stores only a SHA-256 hash of the token in the nativeSession database table. Even in the event of a database compromise, plaintext tokens remain secure.

Unified API Guard

The Fastify server seamlessly handles requests from both environments. The authenticate hook inspects every incoming request:

  1. It first looks for a Authorization: Bearer <token> header, validating it against the nativeSession table.
  2. If no bearer token is present, it falls back to parsing the Cookie header to validate a Better Auth session.

On this page