I&#x27;m confident then that you can skip the base64 encoded header and just have the server use the jwt passed in the bearer token and the new signature you propose. (As the base64 encoded version can be reconstructed from the JWT itself)But I think ideally I would use a wrapped JWT with `&quot;alg&quot;: &quot;ES256&quot;` and just pass it as normal in a bearer token[0] as JWTs natively support signed primitives.[0]: <a href="https:&#x2F;&#x2F;jwt.io&#x2F;#debugger-io?token=eyJhbGciOiJFUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMiwic3VwYWJhc2Utand0IjoiZXlKaGJHY2lPaUpJVXpJMU5pSXNJblI1Y0NJNklrcFhWQ0o5LmV5SnpkV0lpT2lJeE1qTTBOVFkzT0Rrd0lpd2libUZ0WlNJNklrcHZhRzRnUkc5bElpd2lhV0YwSWpveE5URTJNak01TURJeWZRLlNmbEt4d1JKU01lS0tGMlFUNGZ3cE1lSmYzNlBPazZ5SlZfYWRRc3N3NWMifQ.7srrNIhpxeUFb3rPoOJaNQNwsO-IUGAFLSu-UTZtHugfKECt_Tccv-p9KI8h5F7yXMEQcjL7z89LqT7xKYzcWA&amp;publicKey=-----BEGIN%20PUBLIC%20KEY-----%0AMFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAEEVs%2Fo5%2BuQbTjL3chynL4wXgUg2R9%0Aq9UU8I5mEovUf86QZ7kOBIjJwqnzD1omageEHWwHdBO6B%2BdFabmdT9POxg%3D%3D%0A-----END%20PUBLIC%20KEY-----" rel="nofollow">https:&#x2F;&#x2F;jwt.io&#x2F;#debugger-io?token=eyJhbGciOiJFUzI1NiIsInR5cC...</a>

&gt; The recommendation for IP address in the JWT is good, but I don&#x27;t understand your last recommendation of 1) sending the JWT, 2) additionally sending the base64 JWT in a header 3) sending the signature in the header. The crypto.subtle api only works on https domains so you&#x27;re not defending against mitm attacks on unsecure networks either. And if we can&#x27;t trust TLS what can we trust on the web?So here I&#x27;m basically trying to describe what changes you would make to the way JWT validation is currently done. IIRC, the JWT goes over in the headers. I&#x27;m suggesting adding 2 headers - one with the base64 of the json of the JWT, the other header is the ecdsa signature of that.This way, you know whoever it is that logged in and provided their signed public key, has to be sending this request because they signed it with the same key - which is locked to _this_ browser.

I&#x27;ll have to check that out, thanks!If it can store live objects - its perfect.IDB is neat because it can store a PrivateKey Object whose `extractable` attribute has been set to false. So when you try to see the crypto data, you cannot.

Rather than generating key data on the client in the open, and storing it in IDB, I would recommend the Credential Management API[0]. Hand off the responsibility to proper generation and storage to the user agent. Then do your signing of the JWT with them instead.[0]: <a href="https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;Credential_Management_API" rel="nofollow">https:&#x2F;&#x2F;developer.mozilla.org&#x2F;en-US&#x2F;docs&#x2F;Web&#x2F;API&#x2F;Credential_...</a>

Yeah that does it for new keys generated, any old keys in IDB obviously still are exposed.

OH FFS!!!!Serves me right having ChatGPT add commentary and me not double checking.This is what it should be:<pre><code> const keyPair = await crypto.subtle.generateKey(
 { name: &quot;ECDSA&quot;, namedCurve: &quot;P-256&quot; },
 false, &#x2F;&#x2F; this makes it not extractable
 [&quot;sign&quot;, &quot;verify&quot;]
 );
</code></pre>
Run that in HTTPS (here if you want) and try to extract the private key - I don&#x27;t think you can, but could be wrong.

so I don&#x27;t fully understand what you&#x27;re preventing<pre><code> const db = await openDatabase();
 const keyPair = await getKeyPair(db);
 await crypto.subtle.exportKey(&quot;jwk&quot;, keyPair.privateKey)
</code></pre>
exports the private key if I have a XSS vuln.The recommendation for IP address in the JWT is good, but I don&#x27;t understand your last recommendation of 1) sending the JWT, 2) additionally sending the base64 JWT in a header 3) sending the signature in the header. The crypto.subtle api only works on https domains so you&#x27;re not defending against mitm attacks on unsecure networks either. And if we can&#x27;t trust TLS what can we trust on the web?

Its an extremely solid idea, fast, and able to be rolled out without any modifications to the browser.I&#x27;d love to see IDPs adopt the concept. Coupled with passkeys; it seems like it would be extremely difficult to break into someone else&#x27;s account (not impossible, but this definitely adds an order or 2 of difficulty)

Hat off, You made it! After reading and skimming Show HN: Device-Bound Session Tokens in JavaScript ( <a href="https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40052684">https:&#x2F;&#x2F;news.ycombinator.com&#x2F;item?id=40052684</a> ) I had &quot;same&quot; idea to explore PoC, but never done. Thanks!

So the main purpose here is to show _a_ way that session-token theft can be mitigated. Clearly, this isn&#x27;t NSA proof or something you&#x27;d use to secure a BL5 containment facility, but to prevent session-jacking; if feels like it could help a lot, and would be pretty quick and easy to roll out if an IDP wanted to implement it.

Show HN: Storing Private Keys in the Browser Securely