Configure OAuth sign-in for the dashboard

Sign dashboard users in with an OpenID Connect (OIDC) identity provider (IdP) using the authorization code flow with PKCE.

Prerequisites

A public HTTPS URL for the dashboard, such as https://dashboard.example.com.
Permission to register an application (OAuth client) in your IdP.
A Redis for sessions, named in redis.default or dashboard.session.redis. management-api signs users in and the dashboard reads their sessions, so the two share it, and the chart refuses oauth mode without one.

Steps

Register an OAuth client in your IdP with this redirect URI. Where the IdP asks for a sign-out redirect URI, use https://dashboard.example.com/login.
```
https://dashboard.example.com/api/auth/callback
```

Store the client credentials and the session secret in Secrets. Use one Secret with the three keys, or two Secrets.

kubectl create secret generic omnia-dashboard-oauth \
  --namespace omnia-system \
  --from-literal=OMNIA_OAUTH_CLIENT_ID=<client-id> \
  --from-literal=OMNIA_OAUTH_CLIENT_SECRET=<client-secret> \
  --from-literal=OMNIA_SESSION_SECRET=<32-or-more-random-characters>

Set the mode, the provider and the Secret names. The provider settings for each IdP follow.

dashboard:
  baseUrl: https://dashboard.example.com   # no trailing slash
  auth:
    mode: oauth
    existingSessionSecret: omnia-dashboard-oauth
    roleMapping:
      adminGroups: [omnia-admins]
  oauth:
    existingSecret: omnia-dashboard-oauth
    provider: generic   # generic, google, azure, okta or cognito

dashboard.baseUrl builds the callback URL, so a trailing slash produces a callback the IdP rejects. If baseUrl is unset and ingress is on, the chart derives it from dashboard.ingress.host.

Add the provider settings for your IdP.

Generic OIDC:
```
dashboard:
  oauth:
    provider: generic
    issuerUrl: https://auth.example.com
```
Google:
```
dashboard:
  oauth:
    provider: google
```
Google issues no groups claim, so roleMapping and workspace roleBindings match nothing for Google users. Grant them workspace access by email with directGrants instead.

Entra ID (Azure AD). The tenant ID defaults to common. Enable group claims under Token configuration → Add groups claim in the app registration.
```
dashboard:
  oauth:
    provider: azure
    azureTenantId: <tenant-id>
```
Okta. The issuer is https://<domain>. For a custom authorization server such as https://<domain>/oauth2/default, set issuerUrl instead of oktaDomain.
```
dashboard:
  oauth:
    provider: okta
    oktaDomain: your-domain.okta.com
```
Amazon Cognito. Set the user pool’s issuer. The cognito provider requests openid profile email and reads cognito:username and cognito:groups, so role mapping uses Cognito group names. Create the app client with a client secret and the authorization code grant.
```
dashboard:
  oauth:
    provider: cognito
    issuerUrl: https://cognito-idp.<region>.amazonaws.com/<userPoolId>
```
Map other claims if your IdP uses non-default names. Each field overrides one claim and the rest keep the provider’s mapping. groups accepts a nested path.
```
dashboard:
  oauth:
    claims:
      username: preferred_username
      email: email
      displayName: name
      groups: groups
```
dashboard.oauth.scopes replaces the provider’s scope list rather than adding to it. The reference lists each provider’s default scopes and claims.

Apply the values.

helm upgrade --install omnia oci://ghcr.io/altairalabs/charts/omnia \
  --devel --namespace omnia-system -f values.yaml

Verify

Open https://dashboard.example.com. The dashboard redirects you to /login, which shows a Sign in with button named for the provider (Identity Provider for generic, Google, Microsoft or Okta). Select it; the dashboard redirects you to the IdP, and after you sign in it returns you to the dashboard. Then open https://dashboard.example.com/api/auth/session; it returns {"authenticated":true}.

A user in none of adminGroups or editorGroups gets the viewer platform role. To give users access to workspaces, follow Grant workspace access with IdP groups.

Troubleshooting

Confirm the registered redirect URI matches https://dashboard.example.com/api/auth/callback exactly.
Confirm dashboard.baseUrl has no trailing slash.
Confirm the Secret holds the right client ID and secret.
Confirm the IdP grants the requested scopes. Check the dashboard logs for the exact error.

The user is authenticated but has the wrong role

Decode the ID token (for example at jwt.io) and confirm the groups claim is present.
Confirm dashboard.oauth.claims.groups names the claim your IdP uses.
Confirm the values in dashboard.auth.roleMapping.*Groups match the claim values exactly. Entra ID emits group object IDs (GUIDs), not names.

Sign-in fails for Cognito with `invalid_scope`

Use provider: cognito. The generic provider requests a groups scope, which Cognito rejects. If you set scopes yourself, do not include groups.