Maybe this helps on part of this.
Token caching via file is fine - one json file per client, named with the client key, is a clean enough pattern and it scales well.
The actual issue is credentials (email, password, accessToken) living in the workflow itself - pinned node data shows up in execution history and anyone with workflow access can see it in plain text in the workflow JSON.
** The fix I use is ENV VARS. Lload a .env file at n8n startup so the credentials are never in the workflow at all. I wrote up how I do it here:
My other post:
Short version - load a .env file via a bat/shell script at startup, set N8N_BLOCK_ENV_ACCESS_IN_NODE=false, then reference as expression, Variable Anchor like {{ $env.MOSYLE_EMAIL_CR }} etc. The UI will throw a warning saying “not accessible” but it resolves fine at runtime. Per-client you just namespace them: MOSYLE_EMAIL_CLIENT1, MOSYLE_EMAIL_CLIENT2 and so on.
http Request node uses manual header/body params to pass email, password, accessToken — any field accepting expression, so env vars work perfectly there
One thing though - env vars only load at startup, so don’t try to store the bearer token itself there. That part you’ve actually already solved with the file write. The split is: static credentials (email/pass/accessToken) go in .env, dynamic bearer token stays in the json file. Nothing sensitive in the workflow, and your existing token refresh logic keeps working exactly as is.