Talvez isso ajude em parte disso.
Armazenamento em cache de token via arquivo é adequado - um arquivo json por cliente, nomeado com a chave do cliente, é um padrão limpo o suficiente e se escala bem.
O problema real é ter credenciais (email, senha, accessToken) vivendo no próprio workflow - dados de nó fixados aparecem no histórico de execução e qualquer pessoa com acesso ao workflow pode vê-los em texto simples no JSON do workflow.
** O fix que uso é ENV VARS. Carregue um arquivo .env na inicialização do n8n para que as credenciais nunca estejam no workflow. Escrevi como faço isso aqui:
Meu outro post:
Versão resumida - carregue um arquivo .env via script bat/shell na inicialização, defina N8N_BLOCK_ENV_ACCESS_IN_NODE=false, e depois faça referência como expressão, Variable Anchor como {{ $env.MOSYLE_EMAIL_CR }} etc. A UI lançará um aviso dizendo “não acessível”, mas se resolve bem em runtime. Por cliente, você simplesmente os agrupa em namespace: MOSYLE_EMAIL_CLIENT1, MOSYLE_EMAIL_CLIENT2 e assim por diante.
O nó HTTP Request usa parâmetros manuais de header/body para passar email, senha, accessToken — qualquer campo que aceite expressão, então env vars funcionam perfeitamente lá
Uma coisa só - env vars carregam apenas na inicialização, então não tente armazenar o próprio bearer token lá. Essa parte você já resolveu com o file write. A divisão é: credenciais estáticas (email/pass/accessToken) vão em .env, bearer token dinâmico fica no arquivo json. Nada sensível no workflow, e sua lógica de refresh de token existente continua funcionando exatamente como está.