$ feature / offline-licensing

License machines that never connect.

Factory floors, classified networks, ships, and embedded appliances cannot phone home. For those machines AuthForge mints a signed .authforge file in the cloud; the SDK on the air-gapped box verifies it with only your app public key, app id, and its own HWID. No /auth/validate, no check-ins, no network I/O for the life of the file.

Not the grace period

The default product is online activation plus a grace period: the SDK calls login() once, then runs on a signed session for 1 hour to 7 days. That is session continuation, not persistent offline licensing. The machine must reach AuthForge at least once, and again when the session lapses.

An offline license file is a standalone signed document you mint as an operator. Reach for it only when a machine genuinely cannot phone home. Most apps should keep using online login() plus the grace period.

Grace period (default) Offline license file
Network on the end machine Once, at login() Never
What is verified Signed session from /auth/validate Signed document minted by an operator
Revocation Picked up at the next online validate or check-in Not reachable. The file stays valid until its own expiry
Cost 1 credit per login() 1 credit per mint. Verifying is free

How verification works

You mint the file in the dashboard or via POST /v1/licenses/{licenseKey}/offline-files. AuthForge signs it with the same per-app Ed25519 key already used for /auth/validate. The SDK on the air-gapped machine runs a fixed check order: parse armor, verify the signature against every configured public key, then version, shape, app id, expiry, and HWID. The first failure wins, with codes bad_armor, bad_signature, unsupported_version, malformed_payload, wrong_app, expired, hwid_mismatch.

Every official SDK (1.2.0+) exposes loginFromFile (language naming: login_from_file / LoginFromFile). It never starts the grace-period timer or online check-ins. Do not embed the App Secret in those binaries: verification does not use it.

How do I get the customer's HWID?

Bound files need the machine's HWID before you mint. Do not ask the customer to type it into an email: truncation, line-wrapping and autocorrect become hwid_mismatch tickets that look like bugs. Every official SDK writes an activation request (.authforge-request) with no network and no app secret. The customer emails you the file; you paste or upload it in the mint dialog. The dashboard parses it in the browser, checksums it, shows the decoded HWID, and prefills the existing mint. Several machines means several files, accumulated into one mint (up to 16 HWIDs).

Collect the request from the same SDK language that will call loginFromFile. Fingerprints are not portable across languages. HWID is derived from MAC, CPU and disk serial, so a motherboard or disk swap means a new request. This step is not a second product and it is not the grace period.

Honest limits

Revoking a license online blocks new mints and stops online activations. It does not reach files that are already on customer machines. Every issued .authforge file stays valid until its own expiresAt, or forever for lifetime files. There is no remote kill switch.

Mitigate that by minting short-lived, HWID-bound files and re-issuing on a schedule. Prefer 30 to 90 day expiries. An unbound (any) file works on every machine that has a copy. Mint lifetime files only for perpetual licenses where you accept that the entitlement is permanent.

Pricing

1 credit per successful mint, debited through the same path as /auth/validate (app hourly/daily burn caps apply). Rejected mints are free. Offline verification is free: it never contacts AuthForge and never consumes a credit.

Related

Contact support

Feel free to reach out if you have questions, need help getting set up, or run into something unexpected. We'll get back to you as soon as we can.

Email us at support@authforge.cc