Abstract
lets go
2. Trust
A level of trust can be achieved through using the JSONWebTokens (JWT) authentication system, a standard allowing for data payloads to be ‘digitally signed or integrity protected using a Message Authentication Code (MAC)’ (Jones, et al., 2015). This is the grounding for the trust system, as a data payload signed using the JWT standard, can be verified as originating from the source in question. Using JWTs for trust has the following advantages:
-
Scalability: JWTs are lightweight and do not require the storage of session information on the server. This makes them ideal for use in high-scale systems where storing large amounts of session data can become problematic.
-
Security: JWTs are signed using digital signatures, which makes them difficult to tamper with. This makes them ideal for use in secure systems where the authenticity of data is critical.
-
Portability: JWTs can be easily transported between systems and are not tied to any particular technology or platform. This makes them ideal for use in distributed systems where data needs to be exchanged between multiple parties.
-
Interoperability: JWTs are based on open standards and are widely supported by many programming languages and platforms. This makes them easy to use and implement in a wide range of systems.
In this implementation, the client will store the output ‘token’, made up of the algorithm, payload, and signature components. This contains the payload of the data, meaning the client can store their own data and the signature to prove it’s integrity.
2.1 Signing Algorithms
JWT supports signatures from symmetric algorithms (HMAC), and asymmetric algorithms (RSA, ECDSA and PSA) allowing for 2 differing approaches to trust based on user requirements.
2.1.1 Symmetric Signing
With symmetric signatures, a server must generate a secret key, this should be a large random string of characters and should be stored securely on the server. It is vital that this key can only be accessed by the server, as it is the only variable required to sign a payload. In the wrong hands, this would allow an actor to sign a ‘bad’ payload or alter the contents of the payload for malicious exploitation of the service.
It’s easy to brute force keys with a length of under 6 characters on relatively low performant hardware, so to future proof and ensure the integrity of the system it is recommended to use at least 64 random characters. It’s important that this key doesn’t change during production.
Symmetric keys can be used when data isn’t going to need to be ported to another party, or when the payload only needs to exist for a relatively short period of time. Note that asymmetric signing is a much more robust method of signing payloads.
2.1.2 Asymmetric Signing
On the other hand, using asymmetric signatures would allow the payload to be signed from the private key of a keypair and verified using it’s corresponding public key. This has some benefits of a symmetric signature such as:
- The signing party doesn’t necessarily have to be the verifying party, a payload signed from a private key can be verified using the public key. This means that data from one service can be shared with and verified by 3rd parties, using the originating parties’ public key.
- If a private key is ever exposed it can be revoked, no new payloads can be signed with the key however all previously signed payloads can still be fully verified. A new keypair could be generated, for signing future payloads and the service could seamlessly migrate to the new key.