1

Stateless authentication using e.g. JWT can be dangerous as they are non-revocable and can leak giving full access. But they are really flexible.

I'm considering a scenario where the issued JWT is bound to some asymmetric key pair. It could look as below:

  1. Asymmetric key pair (CryptoKey) is stored in browser in IndexedDb.
  2. User sends login request with hash of generated public key.
  3. Issued access token has claim 'proof_of_possession_hash'.
  4. Every request to resource server from browser to be authorized must use Authorization header with access token and PoP header which is JWT signed by CryptoKey (with very short lifetime, needed to complete ONE request)

The PoP token will contain claims: iss (access token owner), aud (resource server), method (HTTP method which will be used at resource server), jti (so resource server can occasionally revoke PoP)

I'm considering whether it has some issues, or whether is has advantages (security advantages) over just session cookies.

What firstly comes to my mind is that cookies are probably sent with every request and they are vulnerable to some web attacks. And when they leak, attacker has full access.

I will use local storage to store access tokens, and IndexedDB to store CryptoKey. If the private key cannot be exported, is there any way to get unauthorized access to user account, except situation where attacker can access data stored at user disk?

1 Answer 1

2

I think you want to store an access token only as a cookie (secure, httponly, samesite: strict). Local storage can be read via js.

You might want to store an ecdsa private key as unextractable key in the browser and use the public key on the server to verify the signature with the private key over some random server challenge to get proof of posession of the private key and then refresh the access token.

I think it is a cool way to keep users seemlessly logged in on trusted devices. Stealing access tokens from properly flagged cookies is difficult but they can leak on server side or some unknown attack vector may still leak them (even if https).

You can just require thsi rather fast and seemless access-token-refresh to practically revoke access tokens if needed. In addition, you can log out devices by requiring some higher re-log-in with user action (like entering some secret from a pass manager or so) and then establish new private-public key pairs for the trusted browser.

Also, now you can always require refreshing access tokens this seemless way if some critical user action happens like data deletion or so (and the sccess token is not super fresh).

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .