One . preface

as everyone knows ,IdentityServer4 Two types of Token, One is Reference Token, One is JWT Token . The former is characterized by
Token The validity of the Token Centralized control of issuing service , It will persist when it is issued Token, Then each validation needs to Token
Pass to the issuance service for validation , It is a centralized and traditional verification method .JWT Token It is opposite to the former , Each resource service does not need to issue service for verification every time Token
Verification of the effectiveness of , The Token It consists of three parts , The last part contains a signature , It uses asymmetric encryption algorithm when issuing ( abreast of the times JWT Token) Data signature , Yes
Can not be tampered with , It's safe , Interaction with the issuance service , Just get the public key to verify the signature , And the public key can be cached by itself , Continuous use , No more interaction , Unless Token Included
keyid Corresponding Public key not cached ( new ), It will be obtained from the issuing service again . I drew a flow chart , You can check it out :

Here is what I said in the article :

Issuing services : That is generation Token Service for .

Resource services : For user access API resources

Two .JWT Token Security issues

It was narrated in the preface ,JWT Type Token At the time of verification , No need to rely on the issuance service for authentication Token
The effectiveness of , It is a decentralized verification method , This means that the issuing service cannot be centrally controlled Token. If Token After exposure , stay Token
Within the validity period , Will always be used maliciously , What should I do at this time ? There are mainly two aspects , One is to try to avoid being obtained maliciously Token, One is how to control failure if it is obtained maliciously . Listen to the breakdown below .

1. use HTTPS

This way is to avoid being obtained malicious access Token.

HTTPS When transmitting data , The data content is encrypted , It can effectively avoid man in the middle attack , So in use JWT Token It is recommended to adopt the procedure of HTTPS.

2. Add custom Token Failure mechanism

This way is obtained maliciously, how to control failure .

because IdentityServer4 Yes JWT Token, By default, there is no control failure mechanism , So if we want to add this mechanism , Only we customize it , In the next section, I'll give you more details .

Three . custom Token Failure mechanism

1. Simple blacklist mode

seeing the name of a thing one thinks of its function , Just add one Token blacklist , This blacklist suggests the existence of Redis
Equally distributed cache , Database and other media , All resource services can be accessed together . It is not recommended to add local cache in resource service , If you do that , Then every time you add a blacklist, you need to synchronize to each resource service . Each resource service in each validation Token You need to check the blacklist , If it's on the blacklist , Namely
Token invalid .

2. Advanced blacklist mode

In the preceding section 【 Simple blacklist mode 】 There is a very big drawback , Every one of them Token The verification needs to verify whether it is in the blacklist , Under normal conditions , We're normal Token
It's the overwhelming majority , If we use this mechanism , So it's a great waste of resources . So we need to set up a mechanism , To make us think suspicious
Of Token Blacklist verification , So how to judge Token Is it suspicious , I think of a way here .

How to judge Token Is it suspicious :

We're generating Token When , You can add custom Claim
( Identity information unit ), Then we can refer to the website login security mechanism , Then we can add a user ip Of Claim, So we generated it Token Will carry user generated Token Time IP, We verify every time Token Whether it is valid or not , According to the source of the client IP And Token Carried IP Match , If it doesn't match , So it's time Token We can think of it as suspicious , So as to verify the blacklist .

This method is relative to the previous one 【 Simple blacklist mode 】 The pattern is a good step forward .

ad locum , We also need to think about it IP Private information as a user , We will IP Put in Token Time , Need to be right IP Encrypt . because JWT Token The first two parts , Merely base64
Encode nothing more .

Claim Please refer to

3. Strengthen blacklist mode

No matter what 【 Simple blacklist mode 】 still 【 Advanced blacklist mode 】, We were right when comparing blacklists token Make a complete comparison , In this way , There are limitations in some scenarios , I want this user to issue it before a certain time Token It's blacklisted . So we can judge the blacklist
According to users id as well as token Issue time to judge . If you let the rules fail automatically ? We can use the previous settings
token The time of issue plus the token The effective time is equal to the rule expiration time .

4. take Token How to add to the blacklist

We set up the blacklist model in front of us , So our Token When will you join the blacklist , Let users say , my Token It's stolen , You took mine
Token Join the blacklist , This is certainly not realistic . We can log in when we log out , Automatically add a rule to the blacklist , use 【 Strengthen blacklist mode 】 Add user id And the current time as token Issue time to verify . For example, users id1000, This user is in
2018-09-20 12:11 sign out , We can add a rule userid=1000,tokenissuetime=2018-09-20 12:11
, This rule means that only users id by 1000 And token Issue time less than 2018-09-20 12:11 Of token, They're blacklisted token.

At this point, one might say , this token If the user still uses it again , That still works , Why didn't you make him invalid ? We set up the blacklist mode to avoid the user's still valid Token
Being used maliciously by others . For users themselves , It doesn't matter .

5. whole Token Failure mechanism .

whole Token Failure mode , Now I think of two :

1. Replace the key pair of the issuing service , And restart all resource services ( The public key obtained by resource service exists in memory by default , Restart can be lost ). This is the original Token During validation , The corresponding public key will not be found , As a result, the signature verification failed Token invalid .

2. Similar to the front 【 Strengthen blacklist mode 】 How to verify the blacklist , We can verify Token Add two configurations to the process , One is a switch that controls whether this configuration is turned on , One is a certain time , The rule is if it is issued before this time Token All count as invalid Token. This requires resource services to support hot load configuration , This avoids restarting the resource service .

I personally recommend the second way .

Four . Other solutions

The content here is based on comments , I can't think of everything personally , So I sorted out some good proposals in the comments :


JWT The best practice for is to follow the default expiration policy (15 Minutes expired ), He can guarantee it effectively Token The effectiveness of .
Refresh Token It is to ensure that the authentication server and the client granting the token are consistent in terms of access rights , such as Claim May contain the latest access rights , This is a necessary and necessary process .

therefore , Frequent 15 It is necessary to refresh the token in minutes , This is not enough to have a significant impact on the performance of the server .

Five . Write it at the end

The article is a summary of my long-standing ideas ,token join ip There is also a basis id And issuing time verification blacklist is what I accidentally thought of today . If you read this article, there is something you don't understand or you think there is improvement , Or better , Welcome to communicate with me in comments . The problems of this paper , A lot of people have asked me , A lot of discussion was also made , I believe a lot of people are using it ids4 There may be such a problem , So I have a point of view here , Hope to give you a reference , I will implement this idea in the following articles .