Documentation — LoaderAuth

01 / Security model

Separate public client material from privileged control.

Your Windows application receives the identifiers and public verification material required to authenticate. Organisation credentials, database access and management authority stay off the client.

ApplicationPublic app configuration

Device proofPossession-bound request proof

LoaderAuth APIAuthoritative policy decision

SessionShort-lived access state

Do not ship database credentials, management keys or privileged signing material inside an EXE, DLL, JavaScript bundle or configuration file.

02 / Client flow

Use the SDK instead of reimplementing the protocol.

The SDK owns the signing, proof and response-validation behavior expected by the server. A normal client path begins with initialization and ends with server-authoritative validation.

loaderauth::AuthClient auth(config); auto result = auth.initialize(); if (!result.ok) return deny(); result = auth.activate(licence_key); if (!result.ok) return deny(); if (auth.validate().ok) { launch_application(); }

Client API routes include initialization, licence activation, device-session creation, session validation and logout. Production requests must use HTTPS.

03 / Sessions

Session state remains backend-authoritative.

LoaderAuth does not treat a permanent copied token or local boolean as proof of current access. Sessions are short lived and remain subject to server-side licence, device and account state.

Device proof binds sensitive requests to the enrolled device credential.
Replay controls prevent a captured request proof being reused against another request.
Revocation is checked server-side instead of waiting for a client-side expiry timer.

04 / Protected delivery

Verify package metadata before replacing local files.

Protected delivery uses private storage, short-lived grants and integrity metadata. The client should verify the exact expected size and SHA-256 digest before a downloaded file becomes active.

POST /v1/releases/manifest POST /v1/releases/download verify: expected_size verify: sha256 replace: only after integrity succeeds

05 / Management boundary

Management automation belongs on trusted infrastructure.

The management API is intended for trusted server-to-server workflows such as application and licence administration. It is not a client SDK surface.

Management credentials must never be embedded in customer software. Keep them in a trusted backend with scoped permissions and appropriate network restrictions.

06 / Integration rules

Non-negotiable implementation rules.

Require HTTPS for all production traffic.
Use the supplied SDK instead of weakening protocol checks for convenience.
Keep privileged credentials and database access server-side.
Treat LoaderAuth backend state as authoritative for licences and sessions.
Verify signed/integrity metadata before trusting protected downloads.
Validate the complete integration in staging before commercial release.