Skip to main content
A self-hosted Evidence deployment (evidence serve) includes a single built-in access control: shared HTTP Basic Auth (EVIDENCE_BASIC_USER / EVIDENCE_BASIC_PASSWORD), or unauthenticated access on a trusted private network (EVIDENCE_AUTH_DISABLED=true). It does not provide user accounts, single sign-on, or an identity store of its own. To authenticate users against your organization’s identity provider, deploy evidence serve behind an authenticating reverse proxy (also known as an identity-aware proxy). The proxy integrates with your identity provider over OIDC or SAML, enforces sign-in on every request, and forwards only authenticated traffic to Evidence.
Authentication controls who can reach the deployment; it does not scope what each user sees. Every authenticated user is served the same reports, queried against the single warehouse identity defined in connection.yaml. Self-hosted deployments do not enforce per-report access control or row-level security — those are applied against a per-viewer identity available only in Evidence Studio. Deployments that require differentiated access to reports or data should use Evidence Studio.

​
Architecture

The proxy is the sole entry point and the authentication boundary; Evidence runs with its built-in authentication disabled. Evidence does not read the authenticated user’s identity from the proxy, so reports, queries, and filters are the same for every authenticated user.
1

Restrict network access to the proxy

Deploy evidence serve on a private network or internal port that is not publicly routable, so the proxy is the only path to the application. A directly reachable deployment with authentication disabled is unprotected.
2

Disable built-in authentication

Set EVIDENCE_AUTH_DISABLED=true so Evidence treats the proxy as the authentication boundary. HTTP Basic Auth may be retained as an additional layer where required.
3

Configure the proxy against your identity provider

Connect the proxy to your identity provider over OIDC or SAML, and scope access to the appropriate users, groups, or domains. Route the proxy to the Evidence deployment.

​
Supported proxies and providers

Any authenticating proxy that integrates with your identity provider over OIDC or SAML is compatible. Commonly used options include: These integrate with standard enterprise identity providers — including Okta, Microsoft Entra ID, Google Workspace, Auth0, Ping Identity, and OneLogin — over OIDC or SAML.