Protect tokens and identity

What you will do

Keep one stable installation identity and protect its token/cache.

The example intentionally uses a private state directory. It demonstrates the SDK's file behavior, not complete production vault integration.

Platform	Simplest correct starting point
Windows	A per-user LocalAppData directory with user-only ACLs; assess DPAPI or Credential Manager through an appropriate adapter.
macOS	A user-owned application-support directory; assess Keychain for the private token.
Linux	A user-owned application-data directory with restrictive permissions; assess Secret Service availability.
Shared backend	A private path outside the web root, isolated per application tenant/installation.

Do not invent an adapter constructor option. The Python SDK can use its existing keyring support; the other current SDKs' file implementations require assessment before claiming a vault. No vault is installed by the sample.

Preserve the SDK-created installation identity through restarts.
Keep App ID/environment/state namespaces separate.
Never sync activation tokens through a public repository or distribute your activated test directory.
Serialize identity, activation and deactivation writes for the same installation.

Expected result

A restarted app validates the same installation without consuming another seat. Another OS user cannot read its private files.

If it does not work

Deleting identity state is not a license reset. A customer-controlled desktop cannot be made tamper-proof; enforce valuable online operations on your authenticated backend too.

Stage checklist

I checked file permissions on every supported OS.
My app does not ship a private activation token or developer API key.
Unsupported storage/runtime assumptions are resolved before Live.

Next steps

Continue to Stage 12: Deliver licenses to customers

You are here: Stage 11 of 14.