$ 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
-
SDKs
:
six languages with
loginFromFile. - Offline licensing guide : mint, ship the file and public key, verify, re-issue.
- Offline license files (docs) : format, verify order, mint API, and revocation semantics.
- Webhooks : subscribe to license lifecycle events from the dashboard.