OIDC Authentication

OIDC Authentication

OIDC authentication is used when teams want browser-based operator access tied to an existing identity provider.

Xferity supports two browser login modes for the UI:

• auth.mode=oidc
• auth.mode=local

This page covers when to use OIDC instead of local login.

When to use it

Use OIDC in Postgres-backed deployments where the web UI and API are part of normal operations and you want user identity, session handling, and role-aware access.

Prefer OIDC when:

• operators already have an enterprise identity provider
• you do not want a shared local operator credential
• browser access should align with existing internal/customer SSO patterns

Use auth.mode=local instead when OIDC is not available yet, the environment is isolated, or you want a minimal private-deployment operator login model.

What it enables

OIDC-backed access makes it easier to:

• align operator access with existing identity systems
• distinguish viewer and operator activity
• reduce reliance on a single static token for every user

Operational requirements

OIDC requires:

• a Postgres-backed runtime
• an OIDC-compatible identity provider
• auth.mode=oidc
• configured redirect and client settings
• appropriate secret handling for client credentials

Related config

Minimum config shape:

auth:
  mode: oidc
  oidc:
    enabled: true
    issuer_url: https://idp.example.com/realms/main
    client_id: xferity-ui
    client_secret: env:OIDC_CLIENT_SECRET
    redirect_url: https://xferity.example.com/auth/callback

Browser session expectations remain the same as local mode:

• HttpOnly session cookie
• SameSite=Lax
• Secure on HTTPS / trusted forwarded HTTPS
• persisted session state in Postgres
• logout revokes the session and clears the cookie

Documentation posture

Describe OIDC as an authentication integration for operator access. Do not imply it changes protocol trust for partner file exchange itself.