CODEWITHSUNDEEP
jwtblazorwebassembly
Chris A
Chris A

Reputation: 31

Store bearer token in Blazor Client-side Wasm? What's the strategy?

Many good examples available of using ID4 and other approaches to safely get a JWT bearer via PKCE, with refresh, to securely call an API from Blazor Wasm... very helpful. But all the samples say to store JWT in local storage. Is this not dangerous? I think so, but would love to be wrong.

Anyone can copy JWt from local storage with browser dev tools. Sure, make the JWT short lived, but the refresh token needs to be stored someplace, so problem not solved. Sure, API can have audience and scopes... but blazor wasm can call API from ANY origin. Sure, ID provider certs make it impossible to create a new JWT with valid sig....but copied JWTs are still dangerous.

React and Angular SPAs have the same problem, and services live Auth0 go to great lengths with custom JavaScript libs to mitigate this problem.

So, what is the Blazor strategy to store JWT on client between API calls? Can we not just inject a memory singleton to store JWT as part of an "App State" object? Would this approach be safe? Any better ideas? Is wasm "memory" comparably hack-resistant to a native app?

Upvotes: 2

Views: 1535

Answers (1)

Chris A
Chris A

Reputation: 31

Ok, here is what we have come up with. Comments appreciated.

  • It's nice to use the VS scaffolded solution. It saves a lot of time.
  • But the scaffolded solution is very vulnerable to replay attacks since JWT is stored in session storage.

So, we're adding our own custom header with a TOTP (timed one-time password). The shared secret will be obtained at login time and stored only in Wasm memory. This is still not perfect, but we will obfuscate it a lot.

The only big advantage we see from the above versus short-lived JWT stored in Wasm memory is that we don't have to spend time re-coding or overriding the scaffolded JWT behavior.

A minor second advantage is that TOPTs are less overhead than a JWT refresh cycle.

But...we'd love to hear a better idea from some smarter person out there! Hope this helps in the meantime.

p.s. Our main concern is not XSS or man in the middle. It's a replay attack something like this...say we are a wholesaler of small things which are very valuable and easy to sell on the black market. Legit customer employee-user logs in at work, and copies a JWT using browser dev tools. She also copies a post payload ordering some products. She emails these to herself. (She's not a master criminal). She goes home, sparks up postman, changes the ship-to address. (Our API architecture is not really this weak, but just say it is for the moment). She hits send and our API places the order, billed to her work but shipped to her home address. (Again, she's not a master criminal.) This is the main scenario we want to avoid.

We're also worried about phony mal-malware "VPN" replays, but that is a MiM and has nothing to do with Local Storage of the JWT. A happy coincidence is that TOTPs will harden us a lot from this threat too.

Upvotes: 1

Related Questions