A JWT old for new exchange schema

Huang Hong Qing
497915580atqq.com

Keywords: JWT security,JSON Web Token, Refresh, Revoke, invalidate, renewals.

What’s JWT

JWT(JSON Web Token) is a string which contain user public formation and signature.
It is issued by auth server centrally and can be validated by distributed service servers.
The JWT string include three parts which separated by dots , the format is:

xxx.yyy.zzz

The first part xxx is Header, for example:

{
"alg": "HS256",
"typ": "JWT"
}

The second part yyy is Payload, it contain user public information, such as user id, user privilege, and expire time. For example

{
"userid": "123456",
"name": "Zhao qiang",
"privilege":"travel",
"exp":"2016-12-16 10:00:00" 
}

The third part zzz is Signature, it is a secret-key based hash or RSA signature. This part is used make sure that the token is not tampered and is issued by correct auth server. HS256 signature example:

HMACSHA256( 
base64UrlEncode(header) + "." + 
base64UrlEncode(payload), 
secret-key)

Normally client provide username and password to auth server, and the server issued the JWT to client, when client request other service API, client add the token to the HTTP header in every request. like this:

Authorization: Bearer <token> #token=header.payload.signature

Compare to traditional session mechanism, The JWT looks like a session id. Except the two import feature:

1. The session id validation is centralized, The JWT validation is distributed.
2. The session id is just a reference, to get user data, server need to look up a center storage server, The JWT self contain client data, no need maintain state in server side.

For distributed micro service architecture, The JWT is more easy and scalable, especially for mobile application restful API service. 　　

The problem of JWT

There are many advantage of JWT, but a big disadvantage of JWT is that it is very hard to invalidate or revoke a issued token before expire time.
Even use changed password or logout, the issued JWT can’t be invalidate easily. This brings more security problem.
Currently, If we use short-time JWT, the user need to login again and again, it is not usability.
If we use long-time JWT, it is not very security.
In fact, this is not a JWT only problem, all distributed validation credentials have the same problem.

In real living, the visa is a example.
The visa is centralized issued by visa office ( the entry and exit administrator office).
It’s validation is distributed, when you check in a hotel, the waiter will validate your visa self instead of calling visa office.
When you lost your visa, you need report the loss to visa office. There is a invalidate visa list in visa office, but this can’t invalidate the lost visa without delay.

If we need the lost or stolen visa invalidate in real time, To validate visa, the hotel waiter need calling visa office,or look up center database. It breaks the import distributed feature.

One import function of expire time on visa is for security. When we apply visa, we hope the expire time as late as possible, when we lost the visa, we hope the expire time as early as possible.
Short or long, it is a problem, not only for JWT.

Another example is SSL Certificates. The Certificates blacklist does not works as we expected.

The solution for JWT revoke

There are two common ways:

1. Maintain a blacklist in center server, when validate token, check the blacklist.
   This breaks the distributed feature.
2. Use short-time access token and long-time refresh token.
   When access token expire, use the refresh token get new access token.
   For normal user, it looks a little safety, but for hacker, this is not different from using one long-time token only, if hacker can get access token,it is not hard to get refresh token also.

Here provide the third solution called as JWT old for new exchange schema.
Because we can’t invalidate the issued token before expire time, we always use short-time token, such as 30 minute.
When the token expired, we use the old token exchange a new token. The critical point is one old token can exchange one new token only.

In center auth server, we maintain a table like this:

table auth_tokens(
    user_id,
    jwt_hash,
    expire
)

user_id contained in JWT string.
jwt_hash is a hash value of whole JWT string. Such as SHA256.
expire field is optional.

The following is work flow:

1. User request the login API with username and password, the auth server issue one token, and register the token ( add one row in the table. )
2. When the token expired, user request the exchange API with the old token. Firstly the auth server validate the old token as normal except expire checking, then create the token hash value, then lookup above table by user id:
   a. If found record and user_id and jwt_hash is match, then issue new token and update the table.
   b. If found record, but user_id and jwt_hash is not match , it means someone has use the token exchanged new token before. The token be hacked, delete records by user_id and response with alert information.
   c. if not found record, user need login again or only input password.
3. when use changed the password or login out, delete record by user id.

To use token continuously ,both legal user and hacker need exchange new token continuously, but only one can success, when one fail, both need login again at next exchange time.
So if hacker got the token, it can be used short time, but can't exchange new one if legal user exchanged new one next time, because the token valid period is short, it is more security.

If there is no hacker, normal user also need exchange new token periodically ,such as every 30 minutes, this is just like login automatically. The extra load is not high and we can adjust expire time for our application.

The night security problem

In Chinese old village, the older always tell children:

The sun was down,
The day becomes black,
The wind gets colder,
The chickens were back to roost,
Come to home,baby,
Pay attention to the bad.

The night is not as safe as the day instinctively, the same credentials always face to more checking at night than at day, it is a common phenomenon.
The same to the old for new exchange schema.

The hacker likes a owl or a bat likes works at night.

For example, a hacker got the Bob's token, and he knows Bob is sleep at 1:00 am to 6:00 am,
So, the hacker can use the toke at night continuously until Bob get up next day and use the application.

The solution for the problem is we can set a protection period, such as 1:00 am to 6:00 am.
In the period, we don't allow exchange new token, only allow apply new token by password.
If user need to use application in the period, need input password for every token, this is not affect usability.
For most mobile application,this is not a big problem.

The simultaneous login from multiple device

For one account, the JWT old for new exchange schema don't issue multiple normal tokens simultaneously.
In fact, user can login from multiple device simultaneously. It is not a normal login, it works at a hacked state. Multiple logins can't exchange new token continuously.
The feature can be used to simulate attack or be used by user in practice.

The service API Architecture inspired by visa

A JWT is really like a visa, centralized issue and distributed validation.
Contain use public information: id, name, privilege, expire.
There are different privilege in visa, such as study, travel, business,the same as JWT.
Both JWT and visa should not contain user secret information, such as password, credit card number etc.

when design API Architecture, we can think we are design a visual country.
First, we need issue visa to our user through center auth server.
Then, create other services API, such as hotel,restaurant, university etc.
This design is natural and Loose coupling and more scalable.

In my opinion, the login and logout concept is for session, the session is for one services mostly.
For JWT and visa, It is for many distributed services.
The entry and exit concept is more suitable and easier understanding.

The conclusion

The paper provide a JWT old for new exchange schema for JWT security problem.
The solution use short-time token to skip the token invalidation or revoking problem.
It use a exchange schema that avoid to use long-time refresh token and use center database track abnormal attack.
It can detect attack and resist attack in time.
The solution is inspired by the article improved persistent login, thanks a lot.

Reference:
http://jaspan.com/improved_persistent_login_cookie_best_practice
https://stormpath.com/blog/the-ultimate-guide-to-mobile-api-security
https://jwt.io/introduction/
https://tools.ietf.org/html/rfc7519