Low-latency validation

“Low latency” here means your login path stays a single, straightforward request, so time-to-license is dominated by normal HTTPS latency, not extra licensing ceremony.

​

One round trip to authenticate

End-user login is designed around one POST /auth/validate call per attempt: There is no multi-step OAuth redirect, no polling loop, and no second “confirm” call required for a standard successful login.

​

What happens on the wire

After TLS, the server does focused work: resolve the license, check status and expiration, enforce HWID slots and security lists, then sign the response. The SDK verifies that signature with your app’s public key, so integrity checks happen locally without another network hop. Rolling nonces are included so responses are not replayable; the SDK handles nonce generation and verification without complicating your UI code.

​

What actually affects “how fast it feels”

AuthForge does not add a separate “license server” hop beyond this API, so you avoid stacking extra latency from a custom middle tier for basic validation.

​

Background checks are separate

After login, the SDK re-verifies the signed session locally through the grace period, and sends online check-ins only if you enabled them. Neither is part of the initial validation latency your user waits on at startup (unless you block your UI until a check-in completes; usually unnecessary).

​

Going deeper

• Security best practices: Protecting your app secret and verifying auth early.
• API errors reference: Includes signature, nonce, and replay cases for SDK auth.
• SDK best practices: Error handling, grace-period behavior, and online check-ins.
• Core Concepts: Credits, sessions, and HWID binding.