config export omits OAuth (external) identities — a config-DB wipe is not lossless

[ton77v]

Follow-up to #38, where the recommended IaC pattern was:

add a scheduled config export?include_secrets=true (stored securely) → commit that YAML → a wipe becomes lossless and removals become explicit

We've now run that loop headlessly against our production instance (thanks — the login-as path in #38 (comment) works exactly as documented). Reporting one observation against that stated goal, since it looks like it stops the "wipe becomes lossless" property from holding. Your call whether it's intended.

Observation

The export omits auth_source: external (OAuth-provisioned) identities.

Source	Identities
GET /_/api/admin/users	8
GET /_/api/admin/config/export?include_secrets=true	7

The one not in the export is an OAuth-provisioned account whose access_key_id differs from the same person's statically-declared one (they exist as two separate records — one local, one external).

This is consistent with what you already stated in #38 — OAuth users are "DB-only … intentionally not reconciled (so a YAML apply can't delete them)" — so the exclusion may well be deliberate. The part we wanted to flag is the downstream consequence for the IaC pattern.

Why it matters for the #38 recommendation

Because the export can't represent the external slice, committing it does not make a config-DB wipe lossless. Per #38 a wipe recreates OAuth users with new access keys, breaking any credentials they've been issued. So for us:

• the encrypted config DB stays load-bearing indefinitely, and
• our nightly DB backup remains the only recovery path for OAuth identities — it can't be retired in favour of the committed YAML, which was the outcome the export pattern was meant to enable.

Practical blast radius on our side is currently one external identity, so this isn't urgent for us — it's the IaC story we're trying to get straight.

Question

Is excluding external identities from config/export permanent by design?

If so, we'll document the DB backup as a permanent requirement and stop treating the committed export as a complete recovery artifact — that's a fine outcome, we'd just like it to be explicit.

If not, an opt-in flag (something like ?include_external=true, or a separate identities/export) that emits the external records — even in a read-only/restore-only form that a YAML apply still refuses to delete — would make the committed export genuinely complete, and preserve the "no persistent DB needed" direction from #38.

Happy to test either way against our instance.

🦀 sent by Claude Code