Deploy OIDC in production

OIDC sign-in is configured in the DALP Helm chart under global.dalpApp.config.auth.oidcProviders (the shared app config rendered into config.yml). The feature is disabled by default: an empty list keeps local email/password and passkey sign-in active. This page covers enabling a provider safely for a real deployment. Read Configure an OIDC provider for the field meanings first.

Enable a provider in Helm values

The chart ships the provider list empty with a commented example:

global:
  dalpApp:
    config:
      auth:
        # Disabled by default. An empty list keeps local login active.
        oidcProviders: []
        # oidcProviders:
        #   - id: "fusionauth"
        #     displayName: "FusionAuth"
        #     issuer: "https://auth.example.com"
        #     clientId: "dalp"
        #     clientSecret: "${OIDC_PROVIDER_CLIENT_SECRET:-}"
        #     adminClaim: "dalp-admin"

Edit id, displayName, issuer, clientId, and adminClaim directly in values. clientSecret is the one sensitive field; inject it from the OIDC_PROVIDER_CLIENT_SECRET environment variable sourced from a Kubernetes Secret. Add more list entries for multiple providers.

Inject the client secret from a Secret

Source OIDC_PROVIDER_CLIENT_SECRET from a Kubernetes Secret (or your external-secrets / Conjur integration), never from a values literal or a plain ConfigMap.

Enable OIDC wallet verification

OIDC wallet verification (OIDC_MFA) requires two more fields on a provider entry: applicationId (the FusionAuth application id, plain config) and apiKey (sensitive). Source OIDC_PROVIDER_MFA_API_KEY from a Kubernetes Secret, the same way as clientSecret. Never place it in a values literal or a ConfigMap.

global:
  dalpApp:
    config:
      auth:
        oidcProviders:
          - id: "fusionauth"
            issuer: "https://auth.example.com"
            applicationId: "the-fusionauth-application-id"
            apiKey: "${OIDC_PROVIDER_MFA_API_KEY:-}"

OIDC wallet verification is independent of sign-in. A provider with issuer, apiKey, and applicationId set is OIDC-MFA-capable even when clientId and clientSecret are empty, and enabling OIDC wallet verification does not disable local login. You can roll OIDC wallet verification out to a deployment that uses local sign-in or to one that uses OIDC sign-in without changing the login method.

Keep issuer validation fail-safe

requireIssuerValidation defaults to true, keeping RFC 9207 issuer checking on. Keep that default. Disable it only per provider for an IdP that provably lacks RFC 9207 support. FusionAuth is the common case.

Prefer a per-deployment environment variable over a committed false, so a new deployment fails safe (validation on) rather than fail-open:

requireIssuerValidation: ${OIDC_PROVIDER_REQUIRE_ISSUER_VALIDATION:-}

With the variable unset the field resolves to its true default; an operator running FusionAuth sets OIDC_PROVIDER_REQUIRE_ISSUER_VALIDATION=false explicitly. Disabling RFC 9207 still leaves the ID token's iss claim validated against discovery.

Privilege comes from the admin claim

The adminClaim value grants platform admin to any profile carrying it. Treat the IdP as trusted configuration: anyone who can mint that claim at the provider can grant themselves platform admin on DALP.

• Scope who can assign the admin role or group at the IdP.
• Keep adminClaim empty unless the deployment deliberately mints the claim (deny-by-default).
• Roles re-derive on every login, so revoking the claim at the IdP demotes the user on their next sign-in.

Recover from a lockout

Enabling a provider disables local login. A misconfigured provider can lock every user out, and there is no in-band fallback. Recovery requires a redeploy with the provider list emptied:

global:
  dalpApp:
    config:
      auth:
        oidcProviders: []

Redeploying with an empty list restores local email/password and passkey sign-in. Validate provider changes in a staging environment so production never depends on an unverified IdP.

Session cache and role changes

A user's role is part of their session cache key. When a claim change at the IdP changes a user's role, the platform must invalidate the cached session for the new authorization to take effect. Without invalidation, stale authorization persists. Account for cache invalidation when you rely on claim-driven promotion or demotion.

OpenShift parity

Chart changes must stay deployable to on-prem OpenShift clusters. When you add or change OIDC values, mirror them in values-openshift.yaml, the canonical OpenShift override example, in the same change. Source the client secret, and the apiKey when OIDC wallet verification is enabled, through the cluster's secret mechanism (for example Conjur-injected secrets) rather than chart literals.

Rollout checklist

• Provider verified end-to-end in staging (sign-in completes, admin role resolves).
• OIDC_PROVIDER_CLIENT_SECRET sourced from a Secret, not a ConfigMap or values literal.
• OIDC_PROVIDER_MFA_API_KEY sourced from a Secret when OIDC wallet verification is enabled, and OIDC wallet verification exercised end-to-end in staging.
• requireIssuerValidation left at true except for providers proven to lack RFC 9207.
• adminClaim set only when the IdP deliberately mints it; admin role assignment scoped at the IdP.
• values-openshift.yaml updated to match (if deploying to OpenShift).
• Lockout recovery path (empty oidcProviders redeploy) understood and reachable.

If sign-in fails after rollout, see Troubleshooting.