QuiskTech: Understanding QWT

This is the first in our new ‘Quisk Tech’ series, courtesy of Hai Long Yang, Staff Software Engineer at Quisk HQ.


This week we want to shed some light on the way in which we use tokens to securely share and verify data between two parties. QWT (Quisk Web Token) is a lightweight and simplified enhancement to JWT Java implementation for a specific business process with enhanced security.

If you are not familiar with the use of JSON Web Tokens for authentication and information exchange, we recommend visiting JWT https://jwt.io/introduction/ for a quick primer on the advantages of JSON Web Tokens over Simple Web Tokens (SWT) and Security Assertion Markup Language Tokens (SAML).


Security and Tokenization

Some existing open JWT implementations provide convenient APIs to generate and validate JWT tokens, however, its implementation architecture is directly tied to a specific security key or a key store/provider.

If the implementation directly uses a specific secret key, it needs to be stored either in properties file or hardcoded within the code. This leads to security issues related to the key. If the implementation uses a key store/provider to store the security key, then it needs to tie the key store/provider with the application server. Since an application server is often a first target of attacks and hacks, the key store tied to application server node is then also vulnerable to exposure. QWT provides a more secure implementation architecture to solve the above problem.


QWT implementation Architecture

As shown in this simple diagram, QWT implementation decouples the payload signature/encryption process from the main token generation and validation process. The secret key provider can be a separate node on the security server.

This gives QWT the flexibility to work with business applications without the need for a key store/provider in the same application server node, in turn making it easy to scale up security server nodes horizontally when required. The Key Store in the security server can be JKS, SoftHSM, HSM, or any other type, offering significant flexibility compared to other systems.

QWT defines the subject in the token with specific claims and expiry time offset. When generating and validating QWT token, claims of the token should be specific to a defined business subject, and be validated for the subject. For example, QWT token used in simple mobile application where a user logs in, business process would define Mobile application as QWT token subject with claims: userid, DEPARTMENTID, USERNAME, USEREMAILID etc.

QWT token can be used for session management in client/server architecture applications. A valid QWT token can be refreshed to generate a token with the same expiry time offset as the original token expiry time offset and starting at the time as that of the original token.


QWT API in Action

QWT provides following main API methods:


withAlgorithm(String alg),

withExpireTime(long milisecondToBeExpired),

withSubject(String sub),

withParam(String key, String value),

generateToken(String shsmIdentifier, String shsmDigestUrl),

validateWith(String token, String shsmKeyIdentier, String shsmDigestUrl, String subject),



The following is an application code sample to show how straightforward QWT implementation is for our customers in a few important areas:


  1. Generate token
String token =  Qwt.build().withAlgorithm(“HmacSHA512”)



                           .withParam(QwtMposParamKey.FIID.name(), fiId)

                           .withParam(QwtMposParamKey.FIMERCHANTID.name(), fiMerchantId)

                           .withParam(QwtMposParamKey.MERCHANTNAME.name(), merchantName)                            

                           .withParam(QwtMposParamKey.MERCHANTEMAIL.name(), merchantEmail)

                           .generateToken(shsmIdentifier, shsmDigestUrl);


  1. Validate token:
boolean isValid = Qwt.build().validateWith(token, shsmIdentifier, shsmDigestUri, QwtSubject.QUISKMPOS.name());


  1. Refresh token (A valid QWT token can be refreshed to a new token with original token expiry time offset).

  String refreshedToken = qwt.refreshToken();


With this refreshed token, QWT can implement the server side session management as required, with the three steps of generate, validate, and refresh, all being completed in a quicker, and easier way. Importantly, QWT should be seen as a solution that builds on the strengths of the JWT open standard, and delivers a more scalable, more secure solution for our market.

If you have any questions about QWT use, drop us a note in the comments section or reach out to our technology team on twitter @GetQuisk or via email at tech@quisk.co

We’d love to hear from you.