Deploy DALP OIDC single sign-on to production safely

Roll out OIDC sign-in through the DALP Helm chart, inject the client secret safely, keep issuer validation fail-safe, and recover from a lockout.

OIDC sign-in is configured in the DALP Helm chart under global.dalpApp.config.auth.oidcProviders (the shared app config rendered into config.yml). It 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"

The plain fields — id, displayName, issuer, clientId, adminClaim — are edited directly in values. clientSecret is the one sensitive field and is injected from the OIDC_PROVIDER_CLIENT_SECRET environment variable, which must be sourced from a Kubernetes Secret. Add more list entries for multiple providers.

A complete entry disables local login deployment-wide

As soon as one entry has id, issuer, clientId, and clientSecret set, external OIDC becomes the only login method. Stage and verify the rollout in a non-production environment first.

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.

Do not let the client secret land in a ConfigMap

If the secret is interpolated into the rendered config.yml and that file is stored in a ConfigMap, it is unencrypted in etcd and readable by anything with get on configmaps in the namespace. Keep OIDC_PROVIDER_CLIENT_SECRET flowing from a Secret into the pod environment, and confirm your deployment does not bake the resolved value into a committed or ConfigMap-stored config.

Keep issuer validation fail-safe

requireIssuerValidation defaults to true (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

Because enabling a provider disables local login, a misconfigured provider can lock every user out — there is no in-band fallback. Recovery is 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 cached session must be invalidated for the new authorization to take effect — otherwise stale authorization can persist. 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 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.
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.

Deploy OIDC in production