Web App Integrations

Many self-hosted applications already know how to authenticate a user based on different headers. Grafana has its auth.jwt and auth.proxy configurations, which validate and extract user information based on a JWT or trusted header. Jenkins has the Reverse Proxy Auth plugin, which trusts headers containing user information from an allowlisted source. These options exist to allow teams to authenticate with Twingate even though they don’t have direct code access.

Twingate Identity Firewall is the proxy that makes this possible. When you publish an app as a Web App Resource, you configure the Gateway to write the signed token, or individual fields such as the username and Twingate Groups, into the headers that app already reads. The app then handles both authentication and authorization on its own, with no code changes and no OIDC integration.

These guides are for apps you run but can’t modify. If you own the application code, the Web App Developer Guides show how to authenticate users with the Gateway’s signed JWT in your app instead. For the architecture and the full header reference, see the Identity Firewall for Web Apps overview.

Guides

Grafana

Configure stock Grafana’s built-in auth.jwt or auth.proxy configurations to read user information from a signed JWT or trusted header, without plugins or code.

Grafana integration guide

Jenkins

Configure Jenkins with the Reverse Proxy Auth plugin and Role-Based Strategy to read the user from X-Forwarded-User and map their Twingate Groups to Jenkins roles.

Jenkins integration guide

Common Pattern

Every guide here follows the same three steps:

• Configure the app to read identity (and Groups, where the app supports them) from named headers or signed JWT.
• Configure the Gateway to inject those headers using the template variables {{jwt}}, {{username}} and/or {{groups}}.
• Map Groups to permissions in the app, using Twingate Group names as the input.

Users provision on first request, so you don’t pre-create accounts. Moving a user between Twingate Groups changes what they can do in the app on their next request.

Security Model

When possible, configure your application to validate the Twingate Gateway Access Token, sent as a Bearer token in the Authorization header. This is the most secure option, because your app can cryptographically verify the user’s identity. If JWT validation isn’t practical, you can fall back to trusted-header authentication. Because those header values are plaintext, make sure your application only accepts the header if the traffic comes from the Gateway.

Next Steps

• Grafana integration guide
• Jenkins integration guide
• Identity Firewall for Web Apps overview for the header reference and JWT payload
• Web App Developer Guides for verifying the JWT in your own application code

Join us in the community subreddit to share your setup or ask questions.