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 Render 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. Surfaced AUTHORIZER_URL (sync:false, set in Render dashboard) and OAUTH2_1_STRICT in render.yaml.
• 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 Render blueprint 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.