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

# Dashboard authentication

> How the Thoras dashboard authenticates users, and how to configure the two built-in modes: generated htpasswd credentials or OIDC login against your identity provider.

## Overview

The Thoras dashboard ships with authentication enabled by default. Requests hit
an [oauth2-proxy](https://oauth2-proxy.github.io/oauth2-proxy/) sidecar in the
dashboard pod. Only authenticated requests reach the dashboard container.

Two modes are supported, selected via `thorasDashboard.auth.mode`:

* **`htpasswd`** (default): a username and password generated in-cluster on
  first install by the Thoras config-controller. No external setup is required.
* **`oidc`**: OIDC login against your identity provider (Okta, Azure Entra ID,
  or any OIDC-compliant provider). You provide the client credentials in a
  Secret you manage.

```
User -> oauth2-proxy sidecar -> Thoras Dashboard (loopback)
                ^
        htpasswd file OR OIDC IdP
```

Fields under the unused mode's block are ignored, so you can switch modes by
changing `auth.mode`.

<Warning>
  Credentials and session cookies are only meaningful behind TLS. Terminate TLS
  at your ingress before exposing the dashboard beyond `kubectl port-forward`,
  and set `thorasDashboard.auth.cookieSecure: true`. The chart default is
  `false` so that port-forward works over plain HTTP. This default is suitable
  for evaluation only. Safari drops Secure cookies over plain HTTP, so you
  cannot enable `cookieSecure` and use `kubectl port-forward` together from a
  Mac.
</Warning>

## Pick a mode

* [Default (htpasswd) auth](/guides/dashboard-auth/htpasswd): log in with the
  generated credentials, set your own, or supply your own Secret.
* [Okta](/guides/dashboard-auth/okta): OIDC login against Okta.
* [Azure Entra ID](/guides/dashboard-auth/entra): OIDC login against Entra.

Other OIDC-compliant providers work with `provider: oidc`. The Okta and Entra
guides show the general shape.

## Migrating from a hand-rolled oauth2-proxy sidecar

Before chart 5.0, the documented way to protect the dashboard was to add your
own oauth2-proxy container under `thorasDashboard.extraContainers` and retarget
the Service at port `4180`. The chart now ships that sidecar for you. Migrating
keeps your IdP app registration and your existing `oauth2-proxy-secrets` Secret.
Only `values.yaml` changes.

**Remove** the old wiring, noting the values of your existing oauth2-proxy flags
for the next step:

```yaml theme={null}
thorasDashboard:
  service:
    targetPort: 4180 # remove
  extraContainers: # remove the entire oauth2-proxy container
    - name: oauth2-proxy
      # ...
```

**Add** the built-in sidecar configuration, substituting the values you noted:

```yaml theme={null}
thorasDashboard:
  auth:
    mode: oidc
    oidc:
      provider: oidc # or entra-id; reuse your existing --provider value (Okta uses oidc)
      issuerURL: <your --oidc-issuer-url value>
      redirectURL: <your --redirect-url value>
      emailDomains: [yourcompany.com] # your --email-domain value(s)
      existingSecret:
        secretName: oauth2-proxy-secrets
```

The chart reads `client-id`, `client-secret`, and `cookie-secret` from the
existing Secret by default (key names are configurable under
`auth.oidc.existingSecret`). The Service goes back to targeting the dashboard's
`containerPort`, now owned by the chart's sidecar, so no `service.targetPort`
override is needed.

## Bring your own auth

Set `thorasDashboard.auth.enabled: false` if you already gate the dashboard
somewhere else, such as an auth plugin at the ingress or gateway, a service-mesh
policy, or a custom SSO sidecar wired through `thorasDashboard.extraContainers`
and `thorasDashboard.service.targetPort`.

```yaml theme={null}
thorasDashboard:
  auth:
    enabled: false
```

<Warning>
  With built-in auth disabled, the dashboard's nginx listens on
  `thorasDashboard.containerPort` with nothing in front of it. Any workload in
  the cluster that can reach the `thoras-dashboard` Service can then use part of
  the Thoras API without authentication, bypassing the shared `apiClientSecret`.
  Only disable built-in auth if something external gates every request.
</Warning>

## NetworkPolicy and OIDC

If you enable the chart's
[NetworkPolicy](/installation/advanced-setup#networkpolicy) alongside OIDC mode,
the chart opens egress on port `443` from the dashboard pod so the sidecar can
reach your identity provider. Tighten this with a layered policy scoped to your
IdP's hostnames (for example a `CiliumNetworkPolicy` with `toFQDNs`) if your
security posture requires it.

## Further reading

* [oauth2-proxy documentation home](https://oauth2-proxy.github.io/oauth2-proxy/)
* [Configuration overview / full flag reference](https://oauth2-proxy.github.io/oauth2-proxy/configuration/overview)
* [Session storage options](https://oauth2-proxy.github.io/oauth2-proxy/configuration/session_storage)
* [TLS configuration](https://oauth2-proxy.github.io/oauth2-proxy/configuration/tls)