Supported Topologies
All topologies are supported and there are several different options for some of these topologies. We can talk you through the various options to see which is the best for you.
One website that calls One secured API
One Website that calls Many secured API's
A secured API that is used by Many different websites
Client Time vs Server Time
As it is the users browser on their device that is generating the WASM Web Token (WWT), then the token created-time is that of the users device. In most instances, this will be time sync'ed via a time server and will closely match that of your server-side API time. In some instances though, the users clock may not be synchronised.
This causes some security systems to simply fail all requests made. With WWT's you can fail and (optionally) recover, via an Offset time. All subsequent WWT's will now include an offset time and succeed. You may try this out on this websites demonstrator on the Home page.
Because we can essentially synchronise the Client and Server times, then this allows you to configure very short lived token expiry times. Unlike certificates and JWT's, this expiry time is configurable within the server-side API and can be changed at any time. Having very short token expiry times has several security advantages
- minimises token copy & paste attacks
- makes attacks using browser automation tools with the likes of Puppeteer, Selenium and Playwright expensive
- can monitor and secure by session counts
WASM in the Client
WebAssembly (WASM), is ideal for generating client side opaque tokens, as it is both extemely fast, and very difficult to read due to it being a byte-code. Almost every kid out there can read JavaScript, whereas trying to read WASM code is like trying to read assembler code.
WASM in the Server
On the server-side, we had the option of writing the token verify logic in a high level language. But most high level languages can be easily de-compiled into readable code. A bad actor may then be able to use this inside information to attack someone elses API.
By using WebAssembly on the server side, we have a single code base that will run anywhere and is quite opaque to being read.
Yes, it does require using a WebAssembly runtime such as Wasmtime, but most languages have a WebAssembly runtime available to them to use. We supply a .Net Core wrapper that you can use directly if you run a .Net API. If you use a different language, then you can use the c# code as a template to write a similar wrapper in your chosen language.
Client file sizes
On disk sizes (uncompressed)
| File | Size |
|---|---|
| wasm module | 18 KB |
| emscripten js module | 12 KB |
| client js | 2 KB |
Security Features
Below are some of the built-in security features. Not all of the features are listed here, as it is important to keep some of the features internal and secret.
- Short-Lived tokens
- Unique token per request
- Secrets are unique to each customer build
- Decrypt checks (multiple levels)
- Browser checks (to ensure it is running in a web browser)
- 3-way Domain (Origin) checks. This should not be used in lieu of CORS, but in conjunction with CORS
- ApplicationId checks
- ClientId checks
- Time differential checks
- Session duration checks
- Max Number of tokens allowed per session
Client Token Performance
On a Core-i5 laptop, using the Chrome web browser
| Test | Result |
|---|---|
| 1M tokens | 9 seconds |
| >111,000 tokens | 1 second |
| 1 token | 9 Microseconds |
Server Token Performance
On a Core-i5 laptop, using .Net8 and Wasmtime runtime using a single thread
| Test | Result |
|---|---|
| 94,500 tokens | 60 seconds |
| >1,500 tokens | 1 second |
| 1 token | 0.6 Milliseconds |