> ## Documentation Index
> Fetch the complete documentation index at: https://docs.authforge.cc/llms.txt
> Use this file to discover all available pages before exploring further.

# Low-latency validation

> Why AuthForge login stays responsive: one round trip, minimal server work, and fast local crypto checks.

“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:

```mermaid theme={null}
sequenceDiagram
    participant App as Your app
    participant SDK as AuthForge SDK
    participant API as AuthForge API

    App->>SDK: login(licenseKey)
    SDK->>SDK: Collect HWID, build nonce
    SDK->>API: POST /auth/validate (single request)
    API-->>SDK: Signed payload + session material
    SDK->>SDK: Verify Ed25519 signature locally
    SDK-->>App: Success or structured error
```

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](/features/security), 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”

| Factor             | Role                                                                            |
| ------------------ | ------------------------------------------------------------------------------- |
| **Network RTT**    | Usually the largest part of wall-clock time.                                    |
| **Cold TLS / DNS** | First request to a host may be slower; later calls reuse connections.           |
| **Your UX**        | Keep license entry non-blocking; avoid unnecessary work before calling `login`. |

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.

## Heartbeats are separate

After login, the SDK runs [heartbeats](/concepts#heartbeats) on a timer. They are **not** part of the initial validation latency your user waits on at startup (unless you block your UI until a heartbeat completes; usually unnecessary).

## Going deeper

* **[Security best practices](/best-practices/security)**: Protecting your app secret and verifying auth early.
* **[API errors reference](/api/errors)**: Includes signature, nonce, and replay cases for SDK auth.
* **[SDK best practices](/sdk/best-practices)**: Error handling, offline behavior, and heartbeat modes.
* **[Core Concepts](/concepts)**: Credits, sessions, and HWID binding.