Why Logout or Change Password Cannot invalidate token

Previous articleIt has been said that token consists of 3 parts: tokensmetadata，payload，signature，

The signature part is encryption of the payload, and the payload will contain the expiration time of the token.

 

This has an advantage: the server does not need to store the status of this session. As long as the signature is checked, you can know the expiration time, simplify the backend logic, and achieve "statelessness".

But this will also have a disadvantage.As long as the token is issued, the content of this token cannot be changed.。

 

After a user logs in and obtains a valid token, he clicks to log out.

At this ideal state, we hope that this token will no longer take effect, but in fact, as long as we use this token to access the Authenticated resources on the server, the token will still pass.

becauseThe operation of [Login] cannot change the token itself。

 

 

 

Simply, when typing the sign out API, add the user's access token token black list; when backend checks jwt, add to check whether the token exists in the token black list.

The design process is developed below:

 

The first question is: Should this sign out token be persisted?

First of all, the token itself will expire;

Secondly, this new verification method will act on every request that passes the token validation, and this method must be accessed at high frequency;

So, here select cache tokenBlackList via redis.

Every time sign out, it will be set to redis; every time you check the token, it will query this redis value.

 

REDIS is the key value pair method of key and value, and value may be string, list, hash..

For value, you can directly and roughly store the entire token json;

So how should key be designed? Using userId, it is likely to overlap with the redis key of other businesses. It is best to add a business scenario here, such as "TOKEN_BLACK_LIST_userId".

 

Assuming: User A logs in at the same time on device D2 after logging in on device D1 (this scenario is currently allowed);

At this time, user A clicks to log out on device D1, and the server will put itTOKEN_BLACK_LIST_AId : tokenJson Write into redis.

At this time, user A operates on device D2 again. When verifying token, he will go to redis to retrieve data and find itTOKEN_BLACK_LIST_AId, at this time, user A's token is considered invalid.

 

If this is not the scenario we expect, how should we make multiple tokens of the same account not affect each other?Here userId is not suitable as a redis key。

whetherEach token has its own unique idWoolen cloth? This is again the composition of token payload, which does have a unique identifier.jti

{
  "jti": "a1b2c3d4-5678-90ef-ghij-klmnopqrstuv",
  "iss": "the issuer",
  "aud": "the audience",
  "exp": 1630003600,
  "iat": 1630000000,
 ..
}

Therefore, here the key is designed as [TOKEN_BLACK_LIST_tokenId], shaped like "TOKEN_BLACK_LIST_a1b2c3d4-5678-90ef-ghij-klmnopqrstuv".

 

 

Assume: User A operates login on multiple devices D1, D2, D3..., and each device holds an independent token at this time;

If the user "modify password" on device D1 at this time, how can the login of all devices such as D2 and D3 be invalidated?

 

The backend can add the token of the device D1 that proposes "modify password" to the token_black_list, but how do you know how many tokens this user currently holds?

Do I need to store the token every time I log in? But this will obviously increase complexity.

 

We can reexamine the structure of token. Can we find some attributes to use?

{
  "jti": "a1b2c3d4-5678-90ef-ghij-klmnopqrstuv",
  "iss": "the issuer",
  "aud": "the audience",
  "exp": 1630003600,
  "iat": 1630000000,
 ..
}

Here is a very clever and simple way:

Every token will hold itiat Issuance time, assuming that user A determines on device D1 the time when “modify password” ischangedPasswordDate，

After the server has completed the "Modify Password",CanchangedPasswordDate This time is stored on redis, let its key beTOKEN_INVALIDATION_userId, value ischangedPasswordDate；

 

Then, to verify the token on the server side, you need to add these two more verifications:

Query whether the current token exists in TOKEN_BLACK_LIST

Query whether TOKEN_INVALIDATION_userId, if it exists,

        Compare whether the iat time of the current token is earlier than changedPasswordDate, if so, the token is invalid

 

 

redis The expiration time of key-value takes the valid period of token. This article sets the validity period of tokens to be 24 hours, that is, 1440 minutes.

public async Task<GlobalSignOutResponse> SignOutAsync(string accessToken)
     {
         var response = await _authService.SignOutAsync(accessToken);
         await _redisCacheService.SetCache((accessToken), accessToken, 1440); // Minute unit
         return response;
     }

The same applies to the "modify password".

 

        ()
            .AddJwtBearer(options =>
            {
                ..
                 = new JwtBearerEvents
                {
                    ..
                    OnTokenValidated = async context =>
                    {
                        if (await IsAccessTokenExpired(context, services))
                        {
                            ($"The access token is expired as user already signed out or changed password.");
                            (GetTokenExpiredResponse());
                        }
                        await ;
                    }
                };
            });

 

    private string GetTokenExpiredResponse(HttpResponse response)
    {
        if (() is ObjectResult result)
        {
            var payload = ();
             = "application/json";
             = 401;

            return ();
        }
        return ;
    }

    private async Task<bool> IsAccessTokenExpired(TokenValidatedContext context, IServiceCollection services)
    {
        try
        {
            var requestHeader = ["Authorization"];
            var accessToken =  > 0 ? requestHeader[0].Split(" ")[1] : ;
            var redisService = <IRedisCacheService>()
            var blackToken = await ((accessToken));
            return blackToken == accessToken;
        }
        catch (Exception ex)
        {
            (ex, $"Failed to validate access token: {}");
            return true;
        }
    }

 

 

 

 

..