Authentication

Self-hosted has two coexisting auth paths:

OIDC - federated login against your own IdP (Okta, Auth0, Google Workspace, Azure AD, etc.). The primary path for real users.
Break-glass admin - a single email + password configured via env vars, always available regardless of OIDC state. Permanent escape hatch, not a stopgap.

WorkOS is never in the loop. Customer auth events stay inside your VPC.

Break-glass admin

Why it’s permanent

The break-glass admin exists for two scenarios:

Initial bootstrap - you need to log in BEFORE OIDC has been configured, to mint your IdP credentials and run a setup wizard.
OIDC misconfiguration - your IdP’s discovery endpoint went down, your IdP’s clock skewed past JWT expiry, somebody rotated client secrets. The break-glass account lets the on-call engineer log in without rolling back the deployment.

We recommend leaving it configured permanently. One account, well-protected by a strong password (or pre-hashed bcrypt) in your secret store.

Configuring it

Two ways to set the password:

# Plaintext - hashed at boot, bcrypt cost 12, original discarded.
helm install ... \
  --set auth.breakGlass.email=admin@acme.example \
  --set auth.breakGlass.password='supersecret123'

# Pre-hashed - preferred for production. Generate the hash anywhere with bcrypt.
htpasswd -bnBC 12 "" 'supersecret123' | tr -d ':\n'
# → $2y$12$XYZ...

helm install ... \
  --set auth.breakGlass.email=admin@acme.example \
  --set 'auth.breakGlass.passwordHash=$2y$12$XYZ...'

Or via an existing Secret (see Configuration → Skipping the chart’s Secret).

Signing in

POST to /api/auth/break-glass/login:

curl -i https://radar.acme.example/api/auth/break-glass/login \
  -H 'Content-Type: application/json' \
  -d '{"email":"admin@acme.example","password":"supersecret123"}'

Or use the web app’s login page - it renders a “Sign in with email + password” panel when break-glass is configured.

Rotating

Bump the Secret + bounce the Pod:

helm upgrade radar-hub skyhook/radar-hub \
  --namespace radar-hub \
  --reset-then-reuse-values \
  --set 'auth.breakGlass.passwordHash=<new bcrypt hash>'

kubectl -n radar-hub rollout restart deploy/radar-hub-hub

Sessions issued under the old password remain valid until cookie expiry - rotate cookies + bcrypt together if you suspect the old credential leaked.

OIDC

Endpoints

The control plane mounts:

GET /api/auth/oidc/login - top-level navigation kicks off the IdP redirect.
GET /api/auth/oidc/callback - your IdP redirects here on success.

You register the callback URL with your IdP. It’s the only URL that needs to match exactly - case-sensitive, no path normalization.

IdP-specific recipes

Okta
Auth0
Google Workspace
Azure AD

In Okta admin, create a new OIDC - Web Application.
Sign-in redirect URI: https://radar.acme.example/api/auth/oidc/callback.
Sign-out redirect URI: https://radar.acme.example (optional; only used if your IdP advertises end_session_endpoint).
Grant types: Authorization Code + Refresh Token.

auth:
  oidc:
    issuer: https://acme.okta.com
    clientID: 0oa<...>
    clientSecret: <from Okta>
    callbackURL: https://radar.acme.example/api/auth/oidc/callback
    defaultRole: member

Auth0 dashboard → Applications → Create → Regular Web Application.
Allowed Callback URLs: https://radar.acme.example/api/auth/oidc/callback.
Allowed Logout URLs: https://radar.acme.example.

auth:
  oidc:
    issuer: https://acme.eu.auth0.com
    clientID: <from Auth0>
    clientSecret: <from Auth0>
    callbackURL: https://radar.acme.example/api/auth/oidc/callback
    defaultRole: member

Google Cloud Console → APIs & Services → Credentials → Create Credentials → OAuth client ID → Web application.
Authorized redirect URIs: https://radar.acme.example/api/auth/oidc/callback.
Google’s discovery doc lives at https://accounts.google.com/.well-known/openid-configuration.

auth:
  oidc:
    issuer: https://accounts.google.com
    clientID: <client>.apps.googleusercontent.com
    clientSecret: <secret>
    callbackURL: https://radar.acme.example/api/auth/oidc/callback
    # Use the OAuth `hd` claim for domain restriction at the IdP layer.
    defaultRole: member

Azure Portal → Microsoft Entra ID → App registrations → New.
Redirect URI: https://radar.acme.example/api/auth/oidc/callback (type: Web).
Issue a client secret under Certificates & secrets.

auth:
  oidc:
    issuer: https://login.microsoftonline.com/<tenant-id>/v2.0
    clientID: <app-registration-id>
    clientSecret: <client-secret>
    callbackURL: https://radar.acme.example/api/auth/oidc/callback
    defaultRole: member

Configuring OIDC from the web app

The hub ships a Settings → SSO (Single Sign-On) page. Enter your issuer, clientID, and clientSecret and it generates the exact kubectl create secret generic radar-hub-oidc --from-literal=client-secret=... plus the

helm upgrade ... --set-string auth.oidc.issuer=... --set-string auth.oidc.clientID=... --set auth.oidc.clientSecretExistingSecret=radar-hub-oidc

command for you, and shows the redirect URI to register at your IdP. It’s a convenience wrapper - the Helm values remain the source of truth.

Roles

Radar has three roles:

owner - full admin (mint cluster tokens, manage members, view audit log).
member - read + cluster operations (the default).
viewer - read-only.

The IdP does authentication (who you are); the hub does authorization (your role) internally - it does NOT read or sync IdP groups. Role assignment:

The first user to sign in - via OIDC or break-glass - bootstraps the org and becomes owner.
Every subsequent new user joins as auth.oidc.defaultRole (default member).
An owner promotes or demotes anyone else from Settings → Members in the web app.

Roles are stored in the hub, not derived from the ID token, so a user keeps their role across logins regardless of any IdP group change.

Session lifetime

The control plane mints a sealed session cookie scoped to its own lifetime - it does NOT silently refresh against the IdP. When the cookie expires (default 7 days), the web app shows the login page and the user re-auths through the IdP.

IdP offboarding behavior

Because the cookie is the freshness signal (not a per-request IdP probe), there is a window between an IdP-side change and the control plane catching up:

User removed from the IdP keeps a working session until the cookie expires (≤ 7 days) or they sign out. To force-revoke immediately: have an owner remove them from the org via Settings → Members. That cuts org-scoped access right away; the user’s stale cookie still authenticates them as a person but resolves to no org membership.

Sign-out

The web app’s sign-out button calls POST /api/auth/signout, which clears the session cookie and (when the IdP advertises end_session_endpoint in discovery) returns a redirect URL to the IdP’s logout page. Most IdPs advertise this; Google does not.

Personal Access Tokens

PATs (rhp_*) work identically to Cloud:

Mint via Settings → Access tokens (logged-in user only mints their own).
Pin to a single org at mint time.
Used as Authorization: Bearer rhp_... for MCP, skyhook-cli, and any script that can’t carry a browser cookie.

The PAT path is decoupled from OIDC and break-glass - tokens validate against a SHA-256 hash in Postgres, no upstream IdP roundtrip per request.

Get started

Views

In-cluster capabilities

Integrations

Self-hosted setup

Cloud

Reference

Authentication

Break-glass admin

Why it’s permanent

Configuring it

Signing in

Rotating

OIDC

Endpoints

IdP-specific recipes

Configuring OIDC from the web app

Roles

Session lifetime

IdP offboarding behavior

Sign-out

Personal Access Tokens

​Break-glass admin

​Why it’s permanent

​Configuring it

​Signing in

​Rotating

​OIDC

​Endpoints

​IdP-specific recipes

​Configuring OIDC from the web app

​Roles

​Session lifetime

​IdP offboarding behavior

​Sign-out

​Personal Access Tokens

Break-glass admin

Why it’s permanent

Configuring it

Signing in

Rotating

OIDC

Endpoints

IdP-specific recipes

Configuring OIDC from the web app

Roles

Session lifetime

IdP offboarding behavior

Sign-out

Personal Access Tokens