fix(deploy): repair crash-looping CLI flags, wire missing security flags

[lakhansamani]

Summary

• --enable-totp-login/--enable-mfa/--enable-email-otp/--enable-sms-otp don't exist in the authorizer binary; cobra rejects unknown flags and exits 1, so every Railway deploy from this Dockerfile currently crash-loops on boot. Renamed to the current --disable-totp-login/--disable-webauthn-mfa/--disable-email-otp/--disable-sms-otp/--disable-mfa flags.
• Added --url (CWE-640 host-header-injection mitigation — was defined nowhere in this repo), --oauth2-1-strict, --enable-org-discovery.
• Re-pinned the base image from 2.3.0 to 2.4.0-rc.7: 2.3.0 predates the flag rename above and doesn't have the --disable-* flags either. Move to the stable 2.4.0 tag once it ships.

Test plan

• Built this Dockerfile against the real quay.io/authorizer/authorizer:2.4.0-rc.7 image and confirmed the container boots and serves /healthz (previously exited 1 on the phantom flags)
• Deploy via the Railway template and confirm the service stays up

[lakhansamani]

Pushed 2.4.0 config coverage on top of this PR.

Two commits

1. fix: pin 2.4.0-rc.15 and wire --encryption-key — this was already sitting uncommitted in the working tree, mirroring the same change in the helm chart. Committed it as-is rather than folding it into mine, so the two stay separable.
2. feat: wire 2.4.0 flags, document boot-fatal SMTP combo — the new work below.

New flags

Env var	Default	Why
FGA_ALLOW_UNCONSTRAINED_AGENTS	false	A delegated FGA check against a model with no type agent now denies rather than authorizing as the delegating user alone.
MICROSOFT_ALLOWED_TENANTS	(empty)	Restricts which Entra tenants may sign in when MICROSOFT_TENANT_ID is a multi-tenant alias.
OAUTH_ALLOW_UNVERIFIED_PROVIDER_EMAIL	false	nOAuth escape hatch — a social login whose provider did not attest the email no longer reaches an existing account.

Audit result: no template ships a crash-looping default

2.4.0 turned --enable-email-verification with no SMTP into a fatal boot error, and --app-cookie-same-site is now validated at boot. I checked every template for both: all already default ENABLE_EMAIL_VERIFICATION:-false and APP_COOKIE_SAME_SITE:-none, so nothing here breaks on upgrade.

The remaining exposure is an operator setting ENABLE_EMAIL_VERIFICATION=true from the platform's own env UI without SMTP — the container would then exit on start. The README now has an "Upgrading to 2.4.0" section saying so. (Skipped for the demo repo, which has no env table.)

Verified

I did not just eyeball the escaping — a broken CMD here is a container that won't start. For each Dockerfile:

• joined Dockerfile line-continuations the way Docker does, then parsed CMD as JSON — valid
• extracted the script and ran sh -n — syntax ok
• all 3 new flags present

Then ran the extracted script with ./authorizer swapped for echo and no env set, to confirm real expansion rather than assuming it:

--fga-allow-unconstrained-agents=false
--microsoft-allowed-tenants=
--oauth-allow-unverified-provider-email=false

Booleans land on the secure default; the tenant list is empty, which the server reads as unrestricted.

[lakhansamani]

⚠️ Do not merge yet — the pinned image cannot run this config

Checking my own flag wiring against the actual published images turned up a blocker that predates this change but which my commit makes worse. Reporting it rather than quietly reverting.

1. The pinned tag does not exist

2.4.0-rc.15 is not published. The newest tag on quay is 2.4.0-rc.14:

$ docker run --rm quay.io/authorizer/authorizer:2.4.0-rc.15
manifest for quay.io/authorizer/authorizer:2.4.0-rc.15 not found: manifest unknown

$ curl -s 'https://quay.io/api/v1/repository/authorizer/authorizer/tag/?onlyActiveTags=true'
2.4.0 tags: rc.0, rc.2 … rc.13, rc.14      # no rc.15

So as pinned, this is an image-pull failure before any flag is parsed.

2. rc.14 does not have the new flags either — and unknown flags are fatal

$ docker run --rm ...:2.4.0-rc.14 -c './authorizer --help | grep -E "fga-allow-unconstrained|microsoft-allowed-tenants|oauth-allow-unverified|encryption-key"'
(no output)

--help itself works — the flags genuinely are not in that build, including --encryption-key from the earlier commit. And cobra refuses to start on an unrecognised flag:

$ docker run --rm ...:2.4.0-rc.14 -c './authorizer --fga-allow-unconstrained-agents=false ...'
Error: unknown flag: --fga-allow-unconstrained-agents
Usage:
  authorizer [flags]

So downgrading the pin to rc.14 as a workaround would turn a pull failure into a crash loop. Both halves are broken.

What this means

The flag wiring here is correct for the server as it now stands on main (PRs authorizerdev/authorizer#751 and #753), but no published image contains it yet. This should merge only after an rc that includes those two PRs is published, and the pin updated to it.

I have not reverted anything — the change is right, the image just has not caught up. Flagging so this does not merge into a deploy that cannot boot.

For the helm chart specifically, the render-time SMTP guard has the same dependency: it blocks a configuration that the currently-pinned image would still accept, since that image lacks the boot-time check.

[lakhansamani]

✅ Blocker cleared — re-pinned to 2.4.0-rc.16

2.4.0-rc.16 is cut and published, and it is the first RC that actually carries this configuration.

What was wrong with rc.15

The tag and GitHub release existed, which is why it got pinned — but its build was cancelled, so no image was ever pushed. It was also cut from 7f34a651, a commit predating the audit, so even a successful build would not have had these flags.

Verified against the published rc.16 image, not the source

All four flags are present:

$ docker run --rm quay.io/authorizer/authorizer:2.4.0-rc.16 -c './authorizer --help | grep -E ...'
--encryption-key string
--fga-allow-unconstrained-agents
--microsoft-allowed-tenants strings
--oauth-allow-unverified-provider-email

And the boot-time check this configuration assumes actually fires:

$ ./authorizer --enable-email-verification=true  (no SMTP)
{"level":"fatal","message":"--enable-email-verification=true requires a working email service,
 but SMTP is not configured. Users would be created unverified with no way to ever verify.
 Set --smtp-host, --smtp-port and --smtp-sender-email, or disable email verification."}

That second check matters here specifically: the render-time guard in this chart exists to catch that combination early, and it would have been guarding against behaviour the pinned image did not have.

No longer blocked from my side.

[lakhansamani]

Re-pinned to 2.4.0-rc.17 — full test gate passed

Moved off rc.16, which was built one commit too early to include the verify-email decision core and the empty-subject token rejection (authorizerdev/authorizer#755).

Both suites green against the exact rc.17 commit

Suite	Result
make test-all-db	exit 0 — 42 packages, 0 failures, all seven backends (internal/storage 215s + arangodb, cassandradb, couchbase, dynamodb, mongodb, sql, schemas)
make e2e-playground	exit 0 — 86 passed (37.7s)

Run sequentially rather than in parallel: no port overlap, but Scylla plus six authorizer instances and browsers contend for CPU, and a false red there costs more than it saves. Both stacks tore down cleanly — zero leaked containers either time.

rc.17 provenance verified two independent ways

Tag SHAs:

rc.17 -> 0ada7ef4   (the #755 merge commit, == main)
rc.16 -> 3f17f68a   (one commit earlier)

And in the published images themselves:

ConsumeEmailVerificationToken:  rc.17 → 3 matches
                                rc.16 → 0 matches

Plus all four new flags present in the rc.17 image (--encryption-key, --fga-allow-unconstrained-agents, --microsoft-allowed-tenants, --oauth-allow-unverified-provider-email).

helm lint clean; the chart renders image: quay.io/authorizer/authorizer:2.4.0-rc.17.

Ready to merge from my side.

[lakhansamani]

Re-pinned to 2.4.0-rc.18

2.4.0-rc.18 bumps cel-go to v0.29.2, clearing GHSA-gcjh-h69q-9w9g (CVSS 6.3).

That advisory was assessed as not exploitable in Authorizer — the vulnerable package is linked in via protovalidate, but neither protovalidate nor OpenFGA nor Authorizer ever calls ext.NativeTypes/ParseStructTag, and exploitation additionally requires attacker-controlled CEL. Bumped regardless, since the fix is a version change.

Verified from the published image, not the manifest

$ go version -m ./authorizer | grep cel-go
github.com/google/cel-go@v0.29.2

Earlier fixes confirmed still present in the same image: all 4 new flags, and the verify-email decision core (ConsumeEmailVerificationToken, 3 matches).

Full test gate re-run on the rc.18 commit

Suite	Result
make test-all-db	exit 0 — 42 packages, 0 failures, all seven backends
make e2e-playground	exit 0 — 86 passed
CI Go tests + release smoke + Trivy	pass

Both stacks tore down clean. helm lint and helm template pass, rendering image: quay.io/authorizer/authorizer:2.4.0-rc.18; each deployment Dockerfile's CMD was re-checked as valid JSON and valid shell after the edit.

Ready to merge.