JWT reprint articles on analysis

Reprinted ultra-detailed analysis of JWT

This article does not discuss how the use Laravel in JWT, to this aspect I can see another article JWT Detailed full use .

Here I want to explore the use of JWT in the practical application of their strengths and weaknesses as well as a deeper level, as well as JWT and Oauth 2.0 both in the end what is the difference and contact.

First, we start from the Token, and then linked to JWT, and then analyze the advantages and disadvantages of JWT and usage scenarios, and finally linked to Oauth2.0.

One, Token

a string is a string token, because generally as authentication credentials, the most common scenario is to use an authentication API.

1. API Authentication

Then the API authentication in general there are several ways it? I probably put together as follows:

cookie + session

As usual web login authentication way, very common, not repeat them.

HTTP Basic

The account number and password and then stitching head base64 encoded header added. Obviously, because the account number and password is almost "expressly" transmission, and each request is passed, the security can be imagined.

HTTP Digest

The account number and password plus some additional information added to the header splice and then take the summary header. This security than the above a little better, because if it is taken summary, even if the pieces of information is intercepted, it can not easily break out (of course also possible to crack).

But in fact, the biggest problem is: take each request for a summary account numbers, passwords, meaning that each request must have the account number and password, that username and password are either cache it, or to go to every request users lose their passwords, this is clearly inappropriate. Also, the above Basic also such a problem.

Token

login authentication token by one, get one authentication string, and then later with the authentication string for subsequent operations, so that you can solve the problem with the account password on every request, and does not need to re-use the account and password .

So we mainly discussed the next token relative to Cookie + Session of the Authentication What are the advantages of it?

2. Token advantage

token Cookie + Session relative advantages, there are the following two:

CSRF attacks

This principle is not much to do introduction, the causes for this attack lies in the way the Session Cookie + authentication, the authentication data (session_id cookie in) carried by the browser is automatically sent to the server, with the help of this feature, the attacker it can allow users to link delays attack, to attack effect. The token itself is the logic applied by the client request as the dynamic parameter, token will not easily leak out, and therefore advantages in CSRF token naturally occurring defense.

For mobile applications

Is not supported on the mobile side cookie, and the token can be stored as long as the client will be able to use, so token on the mobile terminal also has advantages.

3. Token species

Generally token mainly three types:

• Custom token: token developer according to custom business logic
• JWT: JSON Web Token, define a token in the specification RFC 7519
• Oauth2.0: Authorization to define a specification in RFC 6750, but this is actually not a token, but which is also useful to token

Above, I carefully introduced API commonly used authentication methods, and advantages of the token cookie + session with respect. Then followed a careful analysis of JWT.

Two, JWT composition and advantages

JWT stands JSON Web Tokens , is a standardized token. It can be interpreted as a token of this technical specification proposed, in RFC 7519 proposed.

1. Composition

A JWT token is a string that consists of three parts, a head, a load signature, with the intermediate .partition, for example:xxxxx.yyyyy.zzzzz

Head (header)

The header is typically composed of two parts: the token's type (i.e., JWT) and the signature algorithm being used (e.g., HMAC SHA256 or RSA.).
E.g:

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

Then dried Base64Urlto give the coding header, i.e. xxxxx.

Payload (Payload)

Payload placed tokensome basic information to help accept its servers to understand this token. It also may comprise some custom information, user information exchange.

Load property can be divided into three categories:

• Predefined (Registered)
• Public (public)
• Private (private)

Predefined load

{
  "sub": "1",
  "iss": "http://localhost:8000/auth/login",
  "iat": 1451888119,
  "exp": 1454516119,
  "nbf": 1451888119,
  "jti": "37c107e4609ddbcc9c096ea5ee76c667",
  "aud": "dev"
}

The first seven field there are officially defined, it is predefined (Registered claims), and not always necessary.

• iss (issuer): issuer
• sub (subject): Theme
• aud (audience): Audience
• exp (expiration time): Expiration Time
• nbf (Not Before): effective time before this is invalid
• iat (Issued At): The issue of time
• jti (JWT ID): No.

Public loads

When using JWT load can additionally defined. To avoid conflicts, you should use the IANA JSON Web Token Registry in defined, or to add additional load to uniquely identify similar namespace.

Private load

Information exchange between parties good agreement is neither a load nor a predefined load public class load. This class loads may conflict, so it should be used with caution.

The above will jsonbe Base64Urlobtained by coding ,, i.e. load yyyyy.

About loading understanding:

Defines three loads should be clear that this is - for the last two loads, it does not define the kinds of loads, and then let you choose what to load, but you might define the payload out to make a classification.

For example, you define a adminload, the load should be classified according to their private load, it may conflict with others defined. But if you add a prefix (namespace), such as namespace-admin, a public even then it should load up. (But in fact standard does not define how to declare a namespace, so strictly speaking, or may conflict)

But in reality, the team is a good agreement of the payload to be used, in which case, if he did not conflict may exist. Why should such documents define it? My understanding is, RFC is to propose a technical specification, the starting point is a common set of specifications, scope of consideration is that all developers, not just a team of developers. Certification as a token to do is a very common technique, but JWT raised the equivalent of more general set of proposed specifications. Since it is for General Motors, then consider the possibility of conflict in the larger environment is also necessary.

Signed (Signature)

Needed when two string signatures previous encoding had, if HMACSHA256encrypted, is as follows:

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

After encryption base64urlstring encoding is obtained final tokenthird portion zzzzz.

Combined they can get token：xxxxx.yyyyy.zzzzz.

Signature role: to ensure that JWT has not been tampered with, works as follows:

After HMAC algorithm is not reversible algorithm similar to MD5 and hash, but more than one key, the key (that is above secret) held by the server, the client token sent to the server, the server can put them head and a load coupled with the pre-shared secret HMAC encrypted once again, and the results obtained comparing the third paragraph token, it indicates that if the same data has not been tampered with.

Hash-based Message Authentication Code

2. Use

JWT is used in two ways:

• Added to the url:?token=你的token
• Added to the header, we recommend this, because it is more secure in case https:Authorization:Bearer 你的token

JWT clients in storage There are three ways:

• LocalStorage
• SessionStorage
• Cookie [not set HTTPOnly]

But the most recommended or third, because the first two kinds of cross-domain restrictions reading, and Cookie using different cross-domain policy

Because no open HTTPonly, so pay attention to prevent XSS vulnerabilities.

Cookie cross-domain policy

Child can read a parent, but the parent child can not read, can not access each other brothers.

a.xxx.com and b.xxx.com read xxx.com, but can not read each a.xxx.com and b.xxx.com, xxx.com and can not be read a.xxx.com b.xxx. com's.

You might be thinking: I do not keep that Cookie has become and cookie + session as yet?

In actual fact, because only in this cookie store it uses its storage mechanisms, and not to use its authentication. That I just keep it simple, and do not expect the browser to bring up the authentication token, the token request to join this part of the operation carried out manually or me.

3. advantages with respect to the general token

Since JWT is also a token, then it is relative to a normal token What are the benefits of it?

no status

JWT entirely valid because expiration time encoded and its load, the server does not maintain any state, therefore JWT "General" is "stateless" in (why in general, will look in detail later). Stateless biggest advantage is three points:

• Save server resource: server maintenance as a state, so the server can save a previously saved state spent these resources
• Distributed for: Because the server maintenance state, so if the server is composed of multiple servers distributed cluster, you do not need like "stateful" Like synchronized each other's state.
• Time for space: Because the signature verification when verifying the token to the signature verification is consumed CPU time, while "state" is required to provide by the client credentials to the existing state of the server a query , consumption is the I / O and memory, and disk space. Typically for a Web service, its part of I / O intensive, so by the time for space operations, improve overall hardware utilization.

Encoded data

JWT because some of the information can be encoded in the payload, so if the common data encoded into the case, can greatly reduce the number of database queries, but there are two points that need additional attention:

• Plaintext payload information is encoded, the sensitive information can not be encoded in it, if re-encryption prior to encoding can be encoded into
• token will be transmitted in each request, the load information can not be excessive, otherwise it will reduce the transmission efficiency

So there are four advantages of the JWT:

• Anti-CSRF
• For mobile applications
• no status
• Encoded data

The first two are token advantage after two JWT is a unique advantage.

Three, JWT security issues

Since the main usage scenario is authenticated, then the problem is that safety issues have to take into account. The following security issues JWT might need an in-depth discussion and seek the best solutions are carried out.

1. replay attack

Replay attack is the means to carry out attacks by the original packet once playback. You need to clear the cookie + session is also a problem of replay attacks.

Common measures to prevent replay attacks are the following:

timestamp

Entrained in the request a timestamp, set a shorter validity period, request time if a new request exceeds the validity of the request is considered invalid. However, this strategy is also problematic, that is, if a hacker "eye grassland" within the validity period of your package replay, then to attack successfully.

This strategy corresponds to JWT in the token is set to a shorter period.

nonce

Entrained in the request a random string, the string to the client after the client is stored in the blacklist, if the request is a new random string present therein in the blacklist is considered invalid. But obviously, there is a huge problem in this strategy: the need to maintain a blacklist server library, the library will vary with the size of the business run out of time and become very large, thus seriously affecting the efficiency.

This strategy corresponds to the JWT is to set up a blacklist token, but does not set the expiration date.

timestamp + nonce

Entrained in the request a random string and a time stamp, if a new request, which is a random string in the blacklist are considered invalid, the request or a request for more than its expiration date, it is also considered invalid . Just set the scope of such a blacklist is valid timestamp range strategy can be.

This strategy corresponds to the JWT is to set up a token both blacklist, and set an expiration date.

Challenge - response

This fact, and timestamp + nonce strategy as just a random string is generated server to the client, the client service side carries a random string given to the request. So what good is it? The server can be generated by a cryptographic algorithm of this string, making it relevant and time stamp, and the client and can not be forged. This eliminates the need to maintain a blacklist. It is also a time for policy space. But obviously every request will be carried out once or several times with the pre-requisites to obtain a random string is not particularly convenient, resulting in additional consumption has yet to be considered.

serial number

By embedding a sequence number in the request, each request sequentially incremented by one, the sequence number if a request has already been used, is considered invalid. But the use of additional logic of a global serial number, is not particularly convenient.

HTTPS

The ultimate solution, HTTPS automatically maintains an implicit sequence number in the handshake process to solve the above problems to maintain their own serial number.

Note: The above did not discuss client actively replay, interested students can study their own look.

2. token is stolen

Because the token contains the login status, so once the token is stolen, it will be identity theft. So precautions against theft token summarized as follows:

• Use HTTPS transport: to solve the problem from the perspective of the transport layer
• HTTPOnly: to solve the problem from the perspective of the storage layer, to prevent XSS attacks to steal cookie, but this plan is in fact problematic, because it can not read the token js and add it to the header in the head. So do not open HTTPOnly then must pay extra attention to prevent XSS attacks.
• Embedded in the token client fingerprint: fingerprint by the client, even if hackers steal your cookie, he can not request with your cookie.
• Set a shorter token is valid: If this token is stolen, as long as more than a certain time limit can not be used.

Fourth, other issues of JWT

In addition to security issues, JWT there are many other issues to consider.

1. Log out problem

Because JWT is stateless, so it's completely valid by its own decision, that the server can not make a token failure. Obviously this is a big problem, which also has many solutions:

1.1 client initiative to cancel

The client simply delete the cookie store token

This solution is the simplest, is the result of the operation regardless of the client or the server do not have this token, the problem is, this token does not really unusable, but in a free state.

Blacklist policy

To log out of the client carry a cancellation token to access the interface, the token server to join a blacklist.

This strategy is blacklisted too much problem occurs?

The answer is no, because the blacklist only maintain itself has not expired but have to make it invalid token, token expired can not exist blacklist.

1.2 initiative to cancel the service end user to modify the password

Uuid with the token and the key-value pairs stored in redis

This approach appears to be no problem, but in fact, the equivalent of their own to achieve a cookie + session, JWT lost "stateless" this feature, lost a series of advantages "stateless" properties will be brought from .

So that each user has a secret

Issued token mentioned earlier, when used in a secret, thinking of this strategy is to let each user has a secret, a user logout time to modify its secret, to make token issued earlier by check can not fail.

Sounds do not need to maintain a state on this strategy, but in fact there is a greater problem. Imagine, the first option is to find the token to be canceled in the cancellation of the logged on user token table by uuid. cookie + session is to find the corresponding session session_id by the logged-on user's session to log off and delete tables. And this program is by uuid all users (not the logged-in user) to find the secret modifications to unregister. So will you find a lower efficiency, because of the greater Look up.

Pre blacklist

The uuid to unregister the user and the current time (TIME) consisting of key-value pairs added pre blacklist, the next request, and if the corresponding uuid their blacklist, and the time before the issuance of the TIME, which will unregister . Look this is not expired but have to log out users. And this can be pre-blacklist and blacklist signed to do together in the realization of logic.

About blacklist policy supplement:

One might think that the blacklist is a state achieved with this strategy JWT and can not be considered pure stateless. This argument is right, but consider every time you want to retrieve a range of data yields the following relationship:

To log out ahead of time has not expired but the user or token number <all logged users <all users

Here the "<" can be seen as essentially "far less than the" blacklist policy, although it is also considered to have a state, but it maintained the number of states is particularly small.

Visible "blacklist" strategy can effectively solve the problem of cancellation of JWT.

2. renewal problem

session can be automatically renewed, then how token automatically renew it? We first carefully analyze the web and app environments, token respectively how to renew. First detailed analysis of web app renewal and renewal are what specific needs.

web

Over a period of time there is no request, need to login again, this time is generally set to 1-2 hours

app

Over a longer period of time there is no request, it is necessary to log in again, this time is generally 15-30 days

That this requirement can be how to achieve it?

2.1 Method 1

• Refresh the server to take over
• token set a "time expired"
• When the token expires but still within the "refresh" can still refresh
• After more than token expired "refresh time" you can not refresh, you need to log in again

web

Suppose a token issued at 12:00, 2h demand will not be requested to log in again. The expiration time is 1h, the refresh time is 3h.

Then at 12:00 - 13:00 it is working properly, if at 13:00 - 15:00 request, the server automatically get a new token to the client, to achieve renewal.

If 13:00 -15: 00 request is not a request, but rather after 15:00, it is judged expired, you need to log in again.

In this case, the final effect is achieved: the need to log in again after the token expires 2h, rather than token 2h need to re-login is not used, the result is that the user is 2 - 3h is not a request, it is necessary to log in again. Needs to be more than the set one hour uncertain time, but this is not the way to approach, as will the impact on the business, look at the specific needs of bars, most cases still will not.

app

And similar web end, arranged a longer time period to.

Using Laravel developed and used tymon / jwt-auth this developer plug-ins, a place must be noted.

Not be here to refresh token by refreshobtaining a new token this operation, because this token constantly refresh process will reach the upper limit of a refresh time. The above logic is that each time a new issue of a token, as long as the sign will be able to continue to keep using it. Then there's the old token into the blacklist, blacklist period setting to "refresh" as - 3h.

Of course, if the developers continue to feel that this sign would have been able to use is not very good, it may set a longer refresh time, with refreshthe operation to obtain a new token, the refresh time to ensure that each online get token, even if every timely renewal final It will not exceed the refresh time.

Then there will appear a new pit:

If the refresh time is set to 14 days, after which time is set to 2h.

Refresh get token A token B when the "<= 14 days' time if shouting token A request to refresh, is certainly not allowed, otherwise the token issue" becomes 1 N "appears, it is clear that you must set a blacklist but to put these has expired and they have refreshed the token. The validity of this range should be blacklisted token refresh period, ie 14 days. Then you will find that each landing for each user, the number of blacklist token to be maintained up to 14 * 24/2 = 168, black list becomes very large.

So, if you want to use refreshto operate, be sure to refresh time is as small as a multiple of the expiration time.

2.2 Second way

• Every request token are refreshed once
• token set an expiration time
• After the token expires no longer refresh
• token no need to set the refresh time

web

Suppose a token issued 12:00, 2h demand request that is not expired. The setting is valid 2h, you do not need to set the refresh period. Then each request will put a token into a new token. If no request for 2h, then the last request to the token will expire need to log in again. The same sign is constantly able to keep using it.

If you want the same as above, you do not want to permanently renew, set a time to refresh. The refresh time does not lead to further expansion.

app

And similar web end, to set a longer time.

Then to the question of time:

1. Every refresh token, how to impact performance?

   Before each request, the need for a token signature verification, and now it is to issue a new token, a signature operation is carried out, then the amount of computation that is changed from n 2n.

   Secondly, each refresh every old token blacklist, blacklist will lead to particularly large, big refresh period is much more than a way of setting.

2. Every refresh token, because the token will not only lead to a refresh request is successful concurrent requests?

   The answer is indeed cause this problem, how to solve it? Setting a grace period, after each token refresh, the original logic should be immediately unavailable now set a grace period, it is still available to let within n seconds.

In short, this strategy will lead to cost double the CPU operation and led to a huge blacklist, then you must set up a grace period to resolve the problem of concurrent requests, as the grace period will not bring security issues, very little of it.

2.3 blacklist expansion solutions

Mentioned above, for the way a [limited] not been renewed, will lead to a huge blacklist, for the second approach, will always lead to a greater blacklist. That there is no solution? Of course there is.

We may think that since a token has been refreshed, then the issue of time before this refresh can be considered invalid. Then, above the "pre-blacklist" strategy is similar to not refresh when I put a token blacklist, but to uuid-refresh_time composed of key-vakue on the blacklist, so that for each user of each landing, to number of entries into the black list stored in an becomes from the N.

But also consider this question: is a user open two browsers, at different times in the same system have landed (assuming that business permit), then a browser refresh token it could lead to another browser landing failure. So store key-value in the blacklist should be coupled with a key to represent each landing, and this has been key to refresh with JWT's heritage in the payload.

Based on the above optimization, the size of the blacklist becomes: each user while landing and the number of systems, and it will become the same as a cookie + session.

For example, A system (assuming that 2h expiration time, 14 days refresh time), you log in using a browser of your account, I use Chrome browser landed on my account, and then I use QQ browser, and then visit my account , the size is on the blacklist: 2 + 1 = 3

As for the way a [limited] not been renewed, the size of the blacklist (maximum): 168 + 168 * 2

For the second approach, the size of the blacklist are: the number of times your requests within 2h x, y is the number of times I Chrome browser request, I z in the number of requests and QQ browser, namely: x + y + z

2.4 summary

If you want to solve the problem of renewal, a way has been renewed [can] be a better solution, although it will bring a little problem, but will not have much impact. Second way [limited] not been renewed and refreshed each time the blacklist will make maintenance and stateful similar, but there is better security.

3. token there is no need to refresh each time

Let's list the advantages and disadvantages of each refresh token:

advantage:

• Possible renewal
• Can solve replay
• safer

Disadvantages:

• Double CPU consumption
• And the state has almost the same space consumption
• It must be set grace period to resolve concurrency problems

Discussed above, "renewal" and "replay" can be resolved by other means. Only "safer" half a pain point, why is half the pain point? Because if HTTPS, then as long as the means to steal the token on the following way:

• Crack HTTPS
• Handwritten directly from your computer in the past
• XSS [Speaking in front in order to enable js read, you can not set HTTPOnly]

Only there is little possibility of the third method.

So, you do not refresh every time, or you choose it according to the specific business situation.

Five, JWT suitable for what to do

1. stateless RESTful API

This is obviously very fit.

2. SSO single sign-on

Single sign-on must be achieved:

• Session Management: Blacklist and resolved through pre-blacklist
• Renewal: solved by signature solutions

Visible, JWT deployment of some additional logic (blacklist, renewal management) to make JWT instead of cookie + session in most of the scenes.

Six, JWT and Oauth2.0

Oauth 2.0 is doing will not go into it with JWT is not really a level of things. Oauth2.0 is a handy third-party authorization specification, JWT is a token architecture specification. JWT just used to login authentication, authorization and Oauth2.0 also involved in the landing, so relatively easy to confuse.

But in this, I would say, Oauth 2.0 and in fact can be used in conjunction with JWT.

The following is a common Oauth2.0 landing Returns:

{
    "access_token":"kag2geh11a3eh56e23hj",
    "expires_in":7200,
    "refresh_token":"jgko97cq4c8wn69j",
    "scope":"SCOPE" 
}

In the Oauth2.0, access_tokenfor data requests, and refresh_tokento refresh access_token. Each time you refresh, on a access_token will fail, while access_tokenand refresh_tokenobviously have no record of any state, so the state must be maintained for the server.

After the binding and JWT Oauth2.0, such a return may be obtained:

{
    "access_token":"xxx.yyy.zzz",
    "expires_in":7200,
    "refresh_token":"xxxxx.yyyyy.zzzzz",
    "scope":"SCOPE" 
}

After binding has the following advantages:

• Oauth2.0 the token can be achieved without state (although also used the blacklist)
• The token can be included Oauth2.0 common data section
• JWT renewal mentioned earlier, in the case need not be limited been renewed, could lead to expansion of the blacklist, but Oauth2.0 and combined, through refresh_tokenmechanisms, so that the blacklist database token valid from "refresh" turned back "expiration time" to solve this problem.

Seven things to know about the token of ten

This is my article from Auth0 Organization 10 Things You Should Know about Tokens finishing over:

1. Token After obtaining the need to preserve them for future use, you can choose to store in localstorage / sessionstorage / cookie

2. Token is a validity period, you must deploy some logic to control the validity of

3. Cross-domain restrictions localstorage / sessionstorage more stringent than the cookie, cookie recommended

4. When you make an asynchronous request, the browser usually sends a preflight request (option), this should deploy the appropriate back-end logic

   Why OPTIONS request - Cloud + Community - Tencent cloud

5. Use cookie can easily handle a file download request, but the token is generally a request by XHR way, so you have to deploy additional logic. For example, to generate a real-time ticket, to ticket access, and then check, redirect, and finally download the file.

6. XSS process easier than dealing with CSRF (which I really did not see what he is logical, we can go and see the original)

7. token for each request will be coded in the request, please note that the size of the token, not too much encoded data

8. If the encoding sensitive information in the token, the token is encrypted to please

9. Advantages JSON Web Token can be used Bearer Token Oauth2.0 in giving Oauth2.0 stateless

10. Token is not a silver bullet, make a selection based on actual business needs

8 Conclusion

Recently written two articles, courtesy of you care, pointed out that many problems. Recently the company to share, I just intend to questions previously proposed combined with my new understanding to write an article, so there will be, the two previous article, I rearrange the near future a bit, catch some more details, fix some errors, you if you can find it too time to look at.

• JWT full use Comments
• JWT expansion concrete realization Detailed