Let JWT protect your API services

Hello everyone, I am Dayao.

I have written an article about API service specifications before. The original article is here. The focus of the article on security issues is on obtaining tokens through appid, appkey, timestamp, nonce and sign, and using tokens to ensure the security of API services. Today we will talk about a more convenient way to generate tokens using jwt.

1. What is JWT

JSON Web Token(JWT) defines a compact and self-contained way to securely transmit information between parties as a JSON object. The information can be verified and trusted because it is digitally signed. JWT can have an expiration date.

JWT is a very long string, which consists of three parts: Header, Playload and Signature, separated by .

Headers

The Header part describes the basic information of JWT, which generally includes the signature algorithm and token type. The data is as follows:

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

Playload

Playload is where valid information is stored. JWT specifies the following 7 fields, which are recommended but not mandatory:

 iss: jwt issuer
 sub: users that jwt is targeting
 aud: the party receiving jwt
 exp: jwt expiration time, this expiration time must be greater than the issuance time
 nbf: defines the time before which the jwt is unavailable
 iat: jwt issuance time
 jti: unique identifier of jwt, mainly used as a one-time token

In addition, we can also customize the content

 {
 "name" : "Java Journey" ,
 "age" :18
 }

Signature

Signature is the encrypted string of the first two parts of JWT. Headers and Playload are base64 encoded and encrypted using the encryption algorithm and key specified in Headers to obtain the third part of JWT.

2. JWT generation and parsing token

Introducing JWT dependency in application service

 <dependency>
    <groupId>io.jsonwebtoken</groupId>
    <artifactId>jjwt</artifactId>
 <version>0.9.0</version>
 </dependency>

According to the definition of JWT, a token encrypted using the RSA algorithm is generated with a validity period of 30 minutes.

 public   static String createToken( User   user ) throws Exception{ 
 
 return Jwts.builder()
        .claim( "name" , user .getName())
        .claim( "age" , user .getAge())
 // rsa encryption
        .signWith(SignatureAlgorithm.RS256, RsaUtil.getPrivateKey(PRIVATE_KEY))
 // Valid for 30 minutes
        .setExpiration(DateTime.now().plusSeconds(30 * 60).toDate())
 .compact();
 }

After the login interface is verified, JWT is called to generate a token with the user ID and respond to the user. In the next request, the header carries the token for signature verification. After the signature verification is passed, the application service can be accessed normally.

 public   static Claims parseToken(String token) throws Exception{
 return Jwts
 .parser()
        .setSigningKey(RsaUtil.getPublicKey(PUBLIC_KEY))
        .parseClaimsJws(token)
 .getBody();
 }

3. Token renewal issue

The above describes the process of JWT verification. Now let's consider such a problem. The client carries the token to access the order interface. The token is verified, the client places the order successfully, and the order result is returned. Then the client calls the payment interface with the token to make payment. When verifying the signature, it is found that the token is invalid. What should be done at this time? Can only tell the user that the token is invalid, and then ask the user to log in again to get the token? This experience is very bad. Oauth2 does a better job in this regard. In addition to issuing tokens, it will also issue refresh_tokens. When the token expires, it will call refresh_token to re-acquire the token. If the refresh_token is also expired, the user will be prompted to log in again. Now we simulate the implementation of oauth2 to complete the refresh_token of JWT.

The idea is that after the user successfully logs in, a token is issued and an encrypted string is generated as a refresh_token. The refresh_token is stored in redis and a reasonable expiration time is set (the expiration time of the refresh_token is usually set to a longer time). Then the token and refresh_token are responded to the client. The pseudo code is as follows:

 @PostMapping( "getToken" )
 public ResultBean getToken(@RequestBody LoingUser user ){ 
 
    ResultBean resultBean = new ResultBean();
 // User information verification failed, response error
 if(! user ){
 resultBean.fillCode(401, "The account password is incorrect" );
 return resultBean;
 }
 String token = null ;
    String refresh_token = null ;
 try {
 // jwt generated token
        token = JwtUtil.createToken( user );
 // Refresh token
        refresh_token = Md5Utils.hash(System.currentTimeMillis()+ "" );
 // refresh_token expires in 24 hours
        redisUtils.set ( "refresh_token:" +refresh_token,token,30*24*60*60);
 } catch (Exception e) {
 e.printStackTrace();
 } 
 
    Map<String,Object> map = new HashMap<>();
    map.put( "access_token" ,token);
    map.put( "refresh_token" ,refresh_token);
    map.put( "expires_in" ,2*60*60);
 resultBean.fillInfo(map);
 return resultBean;
 }

When the client calls the interface, it carries the token in the request header, intercepts the request in the interceptor, verifies the validity of the token, and if the token verification fails, checks redis to see if it is a refresh_token request. If the refresh_token verification also fails, responds to the client with an authentication exception, prompting the client to log in again. The pseudo code is as follows:

 HttpHeaders headers = request.getHeaders();
 // Get the token in the request header
 String token = headers.getFirst( "Authorization" );
 // Check if there is a token in the request header
 if (StringUtils.isEmpty(token)) {
 resultBean.fillCode(401, "Authentication failed, please bring a valid token" );
 return resultBean;
 }
 if(!token. contains ( "Bearer" )){
 resultBean.fillCode(401, "Authentication failed, please bring a valid token" );
 return resultBean;
 } 
 
 token = token.replace ( "Bearer " , "" );
 // If there is a token in the request header, parse the token
 try {
    Claims claims = TokenUtil.parseToken(token).getBody();
 } catch (Exception e) {
 e.printStackTrace();
    String refreshToken = redisUtils.get( "refresh_token:" + token)+ "" ;
    if(StringUtils.isBlank(refreshToken) || "null" .equals(refreshToken)){
 resultBean.fillCode(403, "refresh_token has expired, please get a new token" );
 return resultbean;
 }
 }

The pseudo code for refreshing_token to exchange for token is as follows:

 @PostMapping( "refreshToken" )
 public Result refreshToken(String token){ 
 
    ResultBean resultBean = new ResultBean();
    String refreshToken = redisUtils.get(TokenConstants.REFRESHTOKEN + token)+ "" ;
    String access_token = null ;
 try {
        Claims claims = JwtUtil.parseToken(refreshToken);
        String username = claims.get( "username" )+ "" ;
        String password = claims.get( "password" )+ "" ;
        LoginUser loginUser = new LoginUser();
        loginUser.setUsername(username);
        loginUser.setPassword( password );
        access_token = JwtUtil.createToken(loginUser);
 } catch (Exception e) {
 e.printStackTrace();
 }
    Map<String,Object> map = new HashMap<>();
    map.put( "access_token" ,access_token);
    map.put( "refresh_token" ,token);
    map.put( "expires_in" ,30*60);
 resultBean.fillInfo(map);
 return resultBean;
 }

Through the above analysis, we have simply implemented the token issuance, verification and renewal issues. As a lightweight authentication framework, JWT is very convenient to use, but there are also some problems.

• The Playload part of JWT is only base64 encoded, so our information is actually completely exposed. Generally, sensitive information should not be stored in JWT.
• The token generated by JWT is relatively long. Carrying the token in the request header each time will cause the request size to be relatively large, which will cause certain performance issues.
• After the JWT is generated, the server cannot discard it and can only wait for the JWT to expire automatically.

The following is a paragraph I saw online about a scenario where JWT is more applicable:

• Short validity period
• Only want to be used once

For example, after a user registers, an email is sent to him to activate his account. Usually, there needs to be a link in the email. This link needs to have the following characteristics: it can identify the user, the link is time-sensitive (usually only allowed to be activated within a few hours), it cannot be tampered with to activate other possible accounts, and it is one-time. This scenario is suitable for using JWT.

This article is reprinted from the WeChat public account "Java Journey", which can be followed through the following QR code. To reprint this article, please contact the Java Journey public account.