Web App Overview

Authentication

The Twingate Client authenticates to the Gateway using a Gateway Access Token (GAT). See How It Works for details. The Gateway handles authentication to the upstream web application on behalf of the user - the browser does not send any application credentials to the Gateway.

After authenticating the user, the Gateway forwards the user's identity to the application by injecting HTTP request headers. The application can use these headers for authentication in one of two ways:

• Verify a signed JWT. The Gateway injects the GAT, a JWT signed by Twingate, in a header such as Authorization: Bearer {{jwt}}. The application verifies the signature against Twingate's public keys and reads the identity from the token's claims. Trust is cryptographic, so the application does not need to assume where the request came from.
• Trust the Gateway and read plain headers. The Gateway injects the identity as plain headers such as X-Twingate-User and X-Twingate-Groups that the application reads directly. Because these are not signed, the application must be reachable only through the Gateway. The Gateway sets these identity headers on every request, overwriting any value a client tried to send, so they cannot be forged.

See Installation for how to configure these headers and the full token contents.

Authorization

Access to the resource is governed by Twingate policy - identity, device posture, and other contextual signals - evaluated before the GAT is issued. The upstream application then authorizes the request based on the identity headers the Gateway injects (for example by validating the forwarded JWT and applying its own role checks).

Audit

The Gateway emits a structured HTTP access log for every request, attributed to the authenticated user. Because these are structured logs on stderr, you can ship them to a storage backend with a standard log pipeline. See Session Recordings for an example log-shipping setup (Vector to GCS) and Monitoring for metrics.