Mutual TLS auth seems like such a no-brainer for APIs like these.

I do wonder, though, how does OpenZiti deal with client certificates expiring? Do you not set/enforce an expiration date or do you have some kind of automated renewal mechanism?

Cert renewal is why it's not used everywhere, I think. While OAuth2 / client credentials is complicated, at least .jwks endpoints make cert rotation easy.

yes, can be tricky, as you state. see above for the openziti approach.

your overlay network fabric infrastructure - ziti edge routers - leverage the ziti edge client API to submit CSRs for new certs x days before expiry.

for client endpoints, there are currently 2 choices and at least 3 in the future:

1. admins chooses to enable client endpoints to continue to auth with expired client certs. the admin revokes access (when necessary) at an endpoint level or at a service level (least privileged access) via those constructs, rather than cert constructs.

2. admins don't permit expired certs to be used. the admin is managing the certs.

3. as a third choice for client endpoints, ziti has plans to enable admins to use the API used by the fabric infra mentioned above. this is future, with timing mainly dependent on openziti community priorities and related work.

The problem is that you hope this doesn't encourage the developers to lapse on RBAC and let an authenticated client do everything.

absolutely. in the case of openziti, the x.509 is the first authentication gate (optionally paired with ziti posture checks and mfa). everything from there is least privileged, attribute-based access, at a service level. default is closed - access to no services (even if authenticated at the level of the private ziti network fabric overlay).