# Web App Integrations for Identity Firewall

Configure off-the-shelf web apps to trust Twingate Identity Firewall headers without code changes.

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](/content/docs/web-app-developer-guides/index.html) 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](/content/docs/web-app-access/index.html).

## 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](/content/docs/web-app-grafana/index.html)

### 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](/content/docs/web-app-jenkins/index.html)

## 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](/content/docs/web-app-access#request-headers/index.html)`{{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](/content/docs/web-app-grafana/index.html)
- [Jenkins integration guide](/content/docs/web-app-jenkins/index.html)
- [Identity Firewall for Web Apps overview](/content/docs/web-app-access/index.html) for the header reference and JWT payload
- [Web App Developer Guides](/content/docs/web-app-developer-guides/index.html) for verifying the JWT in your own application code.