No OAuth client secret in kamo-internal's source; the anonymous token route is gone

Fixkamo-internal
Shipped
September 17, 2026 at 4:40 AM UTC
Author
Kamo
Commit
79215ab

**************** assigned the client-credentials secret for four production client ids (kamo:1:crm:internal, kamo:4:kamo:internal, kamo:5:ebonix:internal, kamo:6:theshortterm:internal) as a string literal, twice, so anyone with the repository held it. **************** carried the same literal and, with no session check, requested an api.read client-credentials token for whatever domain a caller POSTed and handed the token back. Neither did anything useful: no login host serves /oauth2/token (login.kamocrm.com answers 404 to GET and POST), nothing in this or any other repository calls get-user-token-from-login, and kamo-internal's logs held no client- credentials attempt in the last 24 hours. So: - the org route reads AUTH_CLIENT_SECRET from the environment, with no default; without it clientCredentialsAllowed answers missing_dynamic_credentials and the fallback is skipped, which is the outcome the 404 already produced; - get-user-token-from-login is deleted. **************** scans app/ and lib/ for an UPPER_SNAKE *SECRET* constant assigned a string literal. It flags both lines of the previous route, and ignores the label key maps that merely name a clientSecret field. The value remains in git history and in docs/HIPAA_audit_corpus.json's finding; if any system still accepts it, rotate it.

All changes

Like what you see shipping?

All of it arrives in your workspace on its own. Start on the free plan and read this page again in a month.

Start Free ForeverView Pricing