Zum Hauptinhalt springen
Echtzeit-Radar & Feeds
Alle RSS Feeds ➔
👥 Community & Social
Windows Tipps & SecurityGrafikkarte vor Überhitzung schützen: So geht’s(25.09.2026 um 08:00 Uhr)
••••••••••
Windows Tipps & SecurityGrafikkarte vor Überhitzung schützen: So geht’s(25.09.2026 um 08:00 Uhr)
••••••••••
Intelligence View
⚡ tsecurity.de Intelligence

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…

0
↗ Quelle (dev.to)
Reagiere als Erste:r — dein Feedback zählt!

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

1. Sofort-Triage & Abwehrmaßnahmen

SOC Incident Playbook: Vulnerability Remediation & Verification
Syntax validiert (0 Fehler)
title: Detect Exploitation - Signed token between two PWAs: HMAC-SHA256 with no backend
id: b3f9cf83-0663-4f5d-9592-cdb0347d268d
status: experimental
description: Automatisch generierte SIEM-Erkennungsregel basierend auf CTI Intelligence
references:
  - https://tsecurity.de/
author: iShareStuff CTI Automated Detection Engine
date: 2026-09-25
logsource:
  category: network_connection
  product: any
detection:
  selection:
      CommandLine|contains:
        - 'exploit'
  condition: selection
falsepositives:
  - Legitime administrative Zugriffe oder Penetrationstests
level: high
tags:
  - attack.initial_access
Syntax validiert (0 Fehler)
rule CTI_Threat_Indicator {
    meta:
        author = "iShareStuff CTI Automated Detection Engine"
        date = "2026-09-25"
        description = "YARA Signature for "
    strings:
        $str = "Signed token between two PWAs:" ascii wide
    condition:
        any of them
}
Syntax validiert (0 Fehler)
index=security sourcetype IN ("cisco:asa", "pan:traffic", "zeek_conn", "suricata", "WinEventLog:Security")
("Signed token between two PWAs HMAC-SHA25")
| stats count earliest(_time) as first_seen latest(_time) as last_seen by src_ip, dest_ip, dest_host, signature
| eval first_seen=strftime(first_seen, "%Y-%m-%d %H:%M:%S"), last_seen=strftime(last_seen, "%Y-%m-%d %H:%M:%S")
| sort - count
Syntax validiert (0 Fehler)
message: "*Signed token between two PWAs HMAC-SHA25*"
Syntax validiert (0 Fehler)
CommonSecurityLog
| where Message has "Signed token between two PWAs HMAC-SHA25"
| summarize EventCount = count(), FirstSeen = min(TimeGenerated), LastSeen = max(TimeGenerated) by SourceIP, DestinationIP, DestinationPort, Activity
| extend DetectionRule = "iShareStuff-CTI-Compiled"
| sort by EventCount desc

2. Cyber Threat Intelligence & Forensik

🎯
MITRE ATT&CK Matrix Navigator 14 Taktiken
Reconnaissance
-
Resource Development
-
Initial Access
Execution
Persistence
-
Privilege Escalation
Defense Evasion
Credential Access
-
Discovery
-
Lateral Movement
-
Collection
-
Command and Control
Exfiltration
-
Impact
tsecurity.de Cognitive Threat RAG
Fokus-Vektor:

Kognitive Analyse für identifizierte Bedrohung: Erhöhte Bedrohungslage im Bereich Signed token between two PWAs: HMAC-SHA2.... Basierend auf 368k Vektor-Korrelationen werden sofortige Isolationsmaßnahmen für betroffene Endpunkte empfohlen.

🛡️ Angriffsfläche & Exposure

Netzwerk/Remote-Zugriff ohne Vorauthentifizierung möglich.

⚡ Empfohlene Sofortmaßnahmen
  • 1. Perimeter-Inspektion: Relevante Portfreigaben und exponierte Endpunkte unverzüglich scannen.
  • 2. Patch-Applikation: Hersteller-Hotfix einspielen oder betroffene Daemons in isolierte DMZ-Segmente überführen.
  • 3. Telemetrie & EDR-Alerts: Prozessaufrufe und Child-Processes auf anomale Shell-Spawns überwachen.
🔗 Semantisch verwandte Zero-Days MariaDB 11.7 VEC
Ähnliche Beiträge
🔍 Verwandte News

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

Thematisch verwandte Begriffe: Signed, token, between, PWAs · 6 Treffer

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Laden...

Beiträge werden geladen ...

Laden...

Videos werden geladen ...

Zum Aktualisieren ziehen
ZERO-DAY CVE-2026-63208 | Zammad is a web based open source helpdesk/customer support system. Prio…
Advisory →
tsecurity.de Icon
Offline-Lesen, Eilmeldungen & 0ms Ladezeit

Installiere tsecurity.de direkt auf deinen Home-Bildschirm für das ultimative Vollbild-Magazinerlebnis ohne Browser-Leisten.

Nächster Beitrag