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 onboarding 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:

Opzione / Option Come funzionaLimite How it worksDrawback
A — Firebase condiviso Scrive un token su un nodo RTDB comune I due progetti hanno DB separati Writes a token to a shared RTDB node The two projects have separate databases
B — URL firmato HMAC Genera un link con token nel parametro ?auth= Segreto nel client (tool interno, accettabile) Generates a link with token in ?auth= param Secret lives in the client (internal tool, acceptable)
C — postMessage Comunicazione iframe/popup Richiede stesso dominio o apertura controllata 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:

flusso / flow 
// LATO MITTENTE (PanelControl)
payload  = { user: "[OPERATORE]", dept: "Sales", ts: Date.now() }
token    = base64url( HMAC-SHA256(JSON.stringify(payload), SECRET) )
url      = "https://[app-ordini].netlify.app/?auth=" + token + "." + base64url(payload)

// LATO RICEVENTE (Ordini)
[sig, data] = url.searchParam("auth").split(".")
expectedSig = HMAC-SHA256(base64url_decode(data), SECRET)
se sig !== expectedSig → token non valido, accesso negato
se Date.now() - payload.ts > 5 min → token scaduto
altrimenti → window.panelUser = payload.user ✓

The implementation: sender side

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

onboarding.js — PanelControl 
// Segreto condiviso — identico nel sito destinatario
const SHARED_SECRET = 'TuoSegretoCondiviso123!';
const DEST_URL      = 'https://[app-ordini].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 || 'Sconosciuto';

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

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

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

  // Firma il 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.

[brand]-onboarding.html — <head> 
const SHARED_SECRET = 'TuoSegretoCondiviso123!';  // deve essere identico
const TOKEN_TTL_MS  = 5 * 60 * 1000;       // 5 minuti

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

  // Pulisci l'URL subito
  history.replaceState({}, '', location.pathname);

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

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

  // Decodifica la firma da base64url a 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] firma non valida'); return; }

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

  // Controlla scadenza
  if (Date.now() - payload.ts > TOKEN_TTL_MS) {
    console.warn('[auth] token scaduto'); return;
  }

  // Tutto ok — espone l'utente al resto del sito
  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.

[brand]-onboarding.html — badge utente 
// Nel DOMContentLoaded, dopo lo script di verifica
document.addEventListener('panelUserReady', (e) => {
  const badge = document.getElementById('user-badge');
  if (badge) badge.textContent = '👤 ' + e.detail.user;
});

// HTML nell'header
<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.

When this pattern makes sense (and when it doesn't)

When to use it

  • Passing a user between apps in the same internal ecosystem, where both sites are under your control and can share a secret.
  • No sensitive data in the payload: the token only carries an identifier (e.g. operator name), not credentials or personal data.
  • No backend available or not justifiable for such a simple flow — the native Web Crypto API avoids introducing a Cloud Function just to sign a token.
  • Access already restricted upstream (e.g. internal company tool, not publicly exposed).

When not to use it

  • Public or multi-user external apps: the HMAC secret in client code is visible to anyone who opens DevTools — unacceptable if the token needs to guarantee real authentication rather than just passing context.
  • Payload with sensitive data: if the token needs to carry confidential information, it should be signed server-side (e.g. Firebase Custom Token) where the secret never leaves the backend.
  • Need for granular revocation: with a static shared secret you can't invalidate a single token without invalidating all of them — if that level of control is needed, a server-side session system is better.

Alternatives

For a context that requires real authentication (not just transferring a username between two trusted apps), the natural alternative is a Firebase Custom Token generated server-side, which also integrates with RTDB/Firestore security rules instead of remaining an isolated mechanism.

Common mistakes

  • Forgetting time-based expiration: without a timestamp in the payload and a check on the receiving end, an intercepted token URL stays valid forever.
  • Not cleaning the URL after verification: leaving the token in the query string exposes the sensitive-parameter link in browser history and server logs.
  • Treating the HMAC secret as truly secret in a client-side context: it should always be considered a deterrent against casual tampering, not a real security barrier against a motivated attacker.

The result

The operator clicks "Onboarding [BRAND_POS]" 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 badge 👤 [OPERATORE] appears in the header. The user is 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.

Frequently asked questions

Is it safe to keep the HMAC secret in client code?

For an internal business tool, yes: anyone opening DevTools can see the secret, but the token only carries the operator's name, no sensitive data, and access to the site itself is already restricted. For a public app or one handling sensitive data, it's better to sign the token server-side, for example with a Firebase Custom Token or a Node.js endpoint.

Why does the token expire after 5 minutes?

The payload includes a timestamp (ts: Date.now()). The receiving site compares it against the current time and rejects the token if more than 5 minutes have passed. This limits the usable window of a copied or intercepted link, even though the secret itself stays the same.

Do I need a backend to use this approach?

No. Signing and verification both happen entirely in the browser using the native Web Crypto API (crypto.subtle), available in every modern browser with no external libraries. There's no server, intermediate database, or Cloud Function involved in passing the token.

What happens if I change the shared secret?

All previously generated tokens stop working immediately, since the signature computed by the receiving site no longer matches. In practice it doesn't change much: any link older than 5 minutes is already expired anyway due to the timestamp check.

Try the tool

→ Hash Generator: MD5, SHA-1, SHA-256 and more — free, entirely in the browser

Read also

→ PWA push notification center: category drawer, Firestore and FCM service worker → Shared calendar on a PWA: Firebase Realtime Database and FCM push notifications