Native authorization · v1

Product auth for
your EXE or DLL.

Add SYNTRA licensing to Windows C++ software that you own. Every authorization is checked by the server for one product and one device. No offline license or embedded server secret.

Source integration required. A precompiled binary cannot be reliably secured by attaching an API afterward. The host program must call the SDK and disable its protected features when authorization fails.

Before integration

1. Create and publish a product in the SYNTRA admin panel. Copy its ID, for example blackhole.
2. Create a key for that product and let the buyer redeem it on SYNTRA. A key for another product will not work.
3. Build the AegisAuthSdk static library from the C++ source. Link it into your EXE or DLL.
4. Have the user sign in with SYNTRA username/password; if their account has MFA, request the current code.

This product SDK is for member accounts only. Admin and owner accounts can use the separate SYNTRA loader with MFA, but cannot sign in to the product SDK.

API sequence

All requests are HTTPS POST with JSON and X-Aegis-Protocol: 1. Do not send browser cookies or an Origin header.

1. /api/sdk/v1/auth/start

{
  "username": "account_name",
  "password": "account password",
  "code": "optional MFA code",
  "product_id": "blackhole",
  "public_key": "P-256 x||y as 128 lowercase hex characters",
  "key_storage": "tpm"
}

The server checks credentials, account status, the published product, its redeemed unexpired license, and an existing device lock. It returns challenge_id, the exact challenge string and expires_at.

2. /api/sdk/v1/auth/finish

{"challenge_id":"from start","signature":"ECDSA P-256 SHA-256, P1363 r||s lowercase hex"}

Sign the exact UTF-8 challenge bytes. Do not reconstruct them. The challenge is single-use and valid for 60 seconds. The first successful login binds the account to its Windows device key. Success returns an opaque session_token, product ID/name, server time and a 90-second expiry.

3. /api/sdk/v1/challenge → /api/sdk/v1/check

With Authorization: Bearer <session_token>, request {"action":"check"}, sign the new challenge, then send the proof to /check. The server rechecks the exact product license, account and device. A successful check invalidates the old token and returns a new one. Call at least every 30 seconds and before sensitive operations.

4. Logout

Request {"action":"logout"} from /challenge, sign it and send proof to /api/sdk/v1/logout. Clear the local token even if the network is unavailable.

Windows C++ usage

#include "aegis_auth_sdk.h"

aegis::AuthClient auth("blackhole");
auto login = auth.SignIn(username, password, mfaCode);
if (!login.authorized) { DisableProtectedFeatures(); return; }

// Run on a normal worker/timer, at least every 30 seconds:
auto current = auth.Check();
if (!current.authorized || !auth.Authorized()) {
    DisableProtectedFeatures();
    return;
}
// Only now run protected work. Recheck before high-value operations.
auth.SignOut();

In a DLL, initialize the client from an exported function or worker after LoadLibrary. Never call it from DllMain. The example project includes the static library and a console sample.

Errors and fail-closed behavior

Security boundary

Session tokens and challenge IDs are not licenses. The server stores token hashes, binds sessions to a product/device, checks entitlement on every request and rejects replay. A software key is possible; the key_storage value is not TPM attestation. No client-side library can prevent a determined attacker from patching code they control. Keep valuable data or operations on server-validated endpoints where possible. The SDK does not provide anti-debugging, injection, hiding or guaranteed process termination.