Keep Your API Keys Off the Client: A JWT-Gated Upload Facade in Node.js

Every integration a front-end app talks to - Jira, Slack, GitHub, S3 - wants a secret. Put those secrets in the browser and you've published them: anyone can open devtools and lift the token. Proxy each one by hand and you've signed up to maintain eight bespoke integrations.

CloudSend is a small Node.js service that solves both problems. It holds the credentials server-side, exposes a single authenticated upload endpoint, and dispatches to whichever target the client names - so the browser carries a short-lived token and nothing else sensitive.

Part of the engineering behind CloudSend.

Verify at the Front Door

Every request except health and status must present a Bearer JWT. CloudSend verifies it against a configured JWKS endpoint before any route logic executes - an invalid or missing token never reaches the dispatch code:

const jwt = require('jsonwebtoken');
const jwksClient = require('jwks-rsa');

const client = jwksClient({ jwksUri: process.env.JWKS_URI });
const getKey = (header, cb) =>
  client.getSigningKey(header.kid, (err, key) => cb(err, key?.getPublicKey()));

module.exports = function requireJwt(req, res, next) {
  const auth = req.headers.authorization || '';
  if (!auth.startsWith('Bearer ')) {
    return res.status(401).json({ error: { message: 'JWT is missing or invalid.' } });
  }
  jwt.verify(auth.substring(7), getKey, { algorithms: ['RS256'] }, (err, claims) => {
    if (err) return res.status(401).json({ error: { message: 'JWT is missing or invalid.' } });
    req.user = claims;
    next();
  });
};

One Endpoint, Many Targets

Clients don't call Jira or Slack directly - they call CloudSend and name a target_id. A registry of target adapters maps that id to the code (and the server-held secret) that actually talks to the provider:

const TARGETS = {
  jira:   require('./targets/jira'),
  slack:  require('./targets/slack'),
  github: require('./targets/github'),
  s3:     require('./targets/s3'),
};

router.post('/dispatch', requireJwt, async (req, res, next) => {
  const target = TARGETS[req.body.target_id];
  if (!target) return res.status(404).json({ error: { message: 'Unknown target.' } });
  try {
    const result = await target.send(req.body.payload, loadSecret(req.body.target_id));
    res.json({ status: 'ok', result });
  } catch (err) { next(err); }
});

The secret is loaded from server-side storage at request time and handed only to the adapter - it is never serialized into a response or logged.

Why the Facade Wins

The client's world shrinks to two things: obtain a JWT, then POST a payload with a target_id. Adding a ninth integration is a new adapter in the registry, not a change to any client. Rotating a key is a server-side config change nobody downstream notices. And because the token is short-lived and scoped, a leaked one expires instead of exposing a permanent provider credential.

Conclusion: One Integration to Maintain

CloudSend collapses “eight secrets in the browser” into one JWT-gated endpoint with the credentials safely server-side. Verify at the door, dispatch by target id, and keep secrets out of every response - and the client becomes something you can ship publicly without giving anything away.