Developer documentation

Integrate LoaderAuth while keeping privileged secrets off the client.

This public guide describes the client flow and security boundary. Sensitive management credentials remain part of the protected developer workflow.

Architecture overview

LoaderAuth is designed for Windows EXEs, loaders and DLL projects. Customer software carries public application configuration only. Organisation management secrets and database credentials stay off the customer device.

Public website → loaderauth.com Developer portal → admin.loaderauth.com Client API → api.loaderauth.com/v1/* Management API → api.loaderauth.com/v2/management/*

Client API

The current backend exposes these client-facing operations:

GET /v1/health POST /v1/init POST /v1/licenses/activate POST /v1/device/session POST /v1/session/validate POST /v1/session/logout

Use the supplied LoaderAuth SDK rather than reimplementing the protocol manually. The SDK is responsible for the cryptographic and request/response behavior expected by the server.

Device-bound sessions

Activation and resume are separate operations. Device-key proof and rotating short sessions reduce reliance on a copied static token.

Session state remains authoritative on the backend. Do not replace server-side validation with a local boolean or client-only expiry check.

Private releases

Private release delivery uses tenant-scoped state, signed manifests, one-time session-bound grants and SHA-256 verification.

POST /v1/releases/manifest POST /v1/releases/download

Verify the expected hash before trusting a downloaded release payload. A successful HTTP response is not an integrity check by itself.

Management API

The management API is for trusted server-to-server automation, not Windows customer clients. Current routes include application listing and licence management.

POST /v2/management/applications/list POST /v2/management/licenses/list POST /v2/management/licenses/create POST /v2/management/licenses/action

Management credentials can be permission-scoped and IP-restricted. Requests use signing and replay protection. Never place these credentials in an EXE, DLL, JavaScript bundle or public website.

Security rules

  • Require HTTPS for production client and management requests.
  • Keep database credentials and management secrets server-side.
  • Use the supplied SDK and protocol implementation rather than weakening checks for convenience.
  • Treat the LoaderAuth backend as authoritative for subscription, licence and session state.
  • Validate the integration on staging before public registration or payments.
LoaderAuth is currently an Alpha 12 foundation. Public documentation can expand as the SDK surface and commercial launch requirements become final.