Signed token between two PWAs: HMAC-SHA256 with no backend

How I passed the logged-in user’s identity from one PWA to another running on a completely separate Firebase project — without writing a single line of backend code, using only the browser’s Web Crypto API and a signed URL.

The problem: two Firebase projects, no shared state

PanelControl is an internal PWA that manages operators, calendar and chat for a commercial team. From the panel, team members need to open a separate site — let’s call it Orders — running on a completely different Firebase project.

The ask was simple: when an operator clicks “Onboarding”, the destination site must know who they are without a second login. The problem is that the two apps share neither database nor Firebase authentication.

There were three options:

Option	How it works	Drawback
A — Shared Firebase	Writes a token to a shared RTDB node	The two projects have separate databases
B — HMAC signed URL	Generates a link with token in `?auth=` param	Secret lives in the client (internal tool, acceptable)
C — postMessage	iframe/popup communication	Requires same domain or controlled popup opening

With separate databases and a direct link as the entry point, option B is the right call. No extra infrastructure, works immediately.

How HMAC-SHA256 works in the browser

HMAC (Hash-based Message Authentication Code) produces a cryptographic signature of a message using a shared secret key. Without that key, the signature cannot be reproduced — so the receiver knows the sender possesses it.

The Web Crypto API is available in all modern browsers, requires no libraries, and works natively with ArrayBuffer. The flow is:

// SENDER SIDE
payload  = { user: "Alice", dept: "Sales", ts: Date.now() }
token    = base64url( HMAC-SHA256(JSON.stringify(payload), SECRET) )
url      = "https://orders-app.netlify.app/?auth=" + token + "." + base64url(payload)

// RECEIVER SIDE
[sig, data] = url.searchParam("auth").split(".")
expectedSig = HMAC-SHA256(base64url_decode(data), SECRET)
if sig !== expectedSig → invalid token, access denied
if Date.now() - payload.ts > 5 min → token expired
otherwise → window.panelUser = payload.user ✓

The implementation: sender side

The “Onboarding” link became a button that calls an async function. It reads the current user from app state, builds the payload, signs it and opens the link.

// Shared secret — must be identical in the receiver
const SHARED_SECRET = 'YourSharedSecret123!';
const DEST_URL      = 'https://orders-app.netlify.app/';

// Helper: ArrayBuffer → base64url
function buf2b64(buffer) {
  return btoa(String.fromCharCode(...new Uint8Array(buffer)))
    .replace(/\+/g, '-').replace(/\//g, '_').replace(/=/g, '');
}

async function openOnboardingWithToken() {
  const user = state.currentUser?.name || 'Unknown';

  const payload = {
    user,
    dept: state.currentUser?.dept || '',
    ts: Date.now()
  };

  const payloadB64 = buf2b64(
    new TextEncoder().encode(JSON.stringify(payload))
  );

  // Import HMAC key
  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(SHARED_SECRET),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['sign']
  );

  // Sign the payload
  const sigBuffer = await crypto.subtle.sign(
    'HMAC',
    key,
    new TextEncoder().encode(payloadB64)
  );
  const sig = buf2b64(sigBuffer);

  const token = `${sig}.${payloadB64}`;
  window.open(`${DEST_URL}?auth=${token}`, '_blank');
}

Note on token format: I use sig.payload separated by a dot — like JWTs, but without a header. The receiver splits on ., recomputes the signature over the payload and compares.

Receiver side: verification and URL cleanup

In the Orders site, a script in the <head> runs before any other code. It does three things: verifies the signature, checks expiry (5 minutes), and strips ?auth= from the URL so no token remains visible in the browser bar.

const SHARED_SECRET = 'YourSharedSecret123!'; // must be identical
const TOKEN_TTL_MS  = 5 * 60 * 1000;          // 5 minutes

(async () => {
  const params = new URLSearchParams(location.search);
  const auth   = params.get('auth');
  if (!auth) return;

  // Clean the URL immediately
  history.replaceState({}, '', location.pathname);

  const [sig, payloadB64] = auth.split('.');
  if (!sig || !payloadB64) return;

  // Import key in verify mode
  const key = await crypto.subtle.importKey(
    'raw',
    new TextEncoder().encode(SHARED_SECRET),
    { name: 'HMAC', hash: 'SHA-256' },
    false,
    ['verify']
  );

  // Decode signature from base64url to ArrayBuffer
  const sigBytes = Uint8Array.from(
    atob(sig.replace(/-/g, '+').replace(/_/g, '/')),
    c => c.charCodeAt(0)
  );

  const valid = await crypto.subtle.verify(
    'HMAC', key, sigBytes,
    new TextEncoder().encode(payloadB64)
  );

  if (!valid) { console.warn('[auth] invalid signature'); return; }

  // Decode payload
  const payload = JSON.parse(
    decodeURIComponent(escape(atob(
      payloadB64.replace(/-/g, '+').replace(/_/g, '/')
    )))
  );

  // Check expiry
  if (Date.now() - payload.ts > TOKEN_TTL_MS) {
    console.warn('[auth] token expired'); return;
  }

  // All good — expose user to the rest of the site
  window.panelUser = payload.user;
  sessionStorage.setItem('panelUser', payload.user);
  document.dispatchEvent(new CustomEvent('panelUserReady', { detail: payload }));
  console.log('[auth] ✓', payload.user);
})();

Displaying the user in the header

Once window.panelUser is available, the Orders site shows it with an amber badge in the header — giving the operator visual confirmation that their identity was transmitted correctly.

// After the verification script runs
document.addEventListener('panelUserReady', (e) => {
  const badge = document.getElementById('user-badge');
  if (badge) badge.textContent = '👤 ' + e.detail.user;
});

<!-- Header HTML -->
<span id="user-badge" style="
  background: rgba(251,191,36,.15);
  border: 1px solid rgba(251,191,36,.3);
  color: #fbbf24; border-radius: 20px;
  padding: .2rem .75rem; font-size: .8rem;
"></span>

Security considerations

This solution has an explicit limitation: the secret lives in the client code of both sites. Anyone who opens DevTools can see it. For an internal business tool this is acceptable — it’s not a public site and the token only contains the operator’s name, no sensitive data.

⚠️ If you change the shared secret, all previously generated tokens stop working immediately — any link older than 5 minutes was already expired anyway, but good to be aware of.

For a public app or one handling sensitive data, you’d use a server-side signed token (e.g. Firebase Custom Token or a Node.js endpoint), keeping the secret out of the client entirely. But for this context, the client-only solution works perfectly.

The result

The operator clicks the Onboarding button in PanelControl. The browser opens the Orders site with ?auth=TOKEN in the URL. The script verifies the signature in under a millisecond, cleans the URL, and the user badge appears in the header. The user is then available via sessionStorage.getItem('panelUser') throughout the rest of the site’s code.

No intermediate database, no extra backend, no external dependencies. Just native browser cryptography and a shared secret.

Originally published on roversia.it

推荐订阅源

DEV Community