First, application development based on the Session defects
In our traditional B \ S mode application development, we are using session state management, for example: save state information logon, users, permissions and so on. The principle of this method is as follows:
- After user login, saving the state information to a session inside. The server automatically maintained sessionid, about to write sessionid cookie.
- With the HTTP response cookie, it is automatically saved to the browser.
- When a user sends an HTTP request again, sessionid as cookies are brought back to the server
- The server sessionid, the user can retrieve previously stored in the session data inside.
Of course, this entire process, cookies and sessionid both the server and the browser automatically maintained. So from coding level is imperceptible, programmers can only perceive to access session data. However, this approach in some cases, are not applicable.
- For example: non-browser client, mobile phone and so on end, because they do not have browser cookies automatic maintenance functions.
- For example: a distributed application, deploy the same application A, B, C three on the host, load balancing application, one can hang a load of other work. To know the session is stored in the server memory inside, three hosts must be different memory. So when you sign in when visiting the armor, and get access to interface data B, we can not guarantee the uniqueness and the sharing session.
Of course, we have more of these programs (such as redis sharing session, etc.), you can continue to use the session to save the state. But there is another approach is to do a session, that is, development and application of a stateless, JWT is one such program.
Second, what JWT that?
I do not want to use the term on relatively tall explained JWT (JSON web tokens), you may think that JWT is an interface to access the encrypted password, and the password which contains the user name information. This is to know who you are? You can know whether you can access the application?
- First, the client need to apply JWT token to the server, this process is usually login. Namely: JWT in exchange for a token by a user name and password.
- 当你访问系统其他的接口时，在HTTP的header中携带JWT令牌。header的名称可以自定义，前后端对应上即可。
- 服务端解签验证JWT中的用户标识，根据用户标识从数据库中加载访问权限、用户信息等状态信息。
这就是JWT，以及JWT在应用服务开发中的使用方法。
三、JWT结构分析
下图是我用在线的JWT解码工具，解码时候的截图。注意我这里用的是解码，不是解密。
从图中，我们可以看到JWT分为三个部分：
- Header，这个部分通常是用来说明JWT使用的算法信息
- payload，这个部分通常用于携带一些自定义的状态附加信息（重要的是用户标识）。但是注意这部分是可以明文解码的，所以注意是用户标识，而不应该是用户名或者其他用户信息。
- signature，这部分是对前两部分数据的签名，防止前两部分数据被篡改。这里需要指定一个密钥secret，进行签名和解签。
四、JWT安全么？
很多的朋友看到上面的这个解码文件，就会生出一个疑问？你都把JWT给解析了，而且JWT又这么的被大家广泛熟知，它还安全么？我用一个简单的道理说明一下：
- JWT就像是一把钥匙，用来开你家里的锁。用户把钥匙一旦丢了，家自然是不安全的。其实和使用session管理状态是一样的，一旦网络或浏览器被劫持了，肯定不安全。
- signature通常被叫做签名，而不是密码。比如：天王盖地虎是签名，宝塔镇河妖就被用来解签。字你全都认识，但是暗号只有知道的人才对得上。当然JWT中的暗号secret不会设计的像诗词一样简单。
- JWT服务端也保存了一把钥匙，就是暗号secret。用来数据的签名和解签，secret一旦丢失，所有用户都是不安全的。所以对于IT人员，更重要的是保护secret的安全。
如何加强JWT的安全性？
- 避免网络劫持，因为使用HTTP的header传递JWT，所以使用HTTPS传输更加安全。这样在网络层面避免了JWT的泄露。
- secret是存放在服务器端的，所以只要应用服务器不被攻破，理论上JWT是安全的。因此要保证服务器的安全。
- Is there a possibility JWT encryption algorithm is compromised? Of course. But for JWT commonly used algorithms in order to break the method currently known only brute force, white words, "try the password." It should be changed regularly and Yasumasa secret secret of complexity, such as cracking the results came out, your secret has changed.
Anyway, if your server or your team of internal staff loopholes, again without a protocol and algorithm is secure.
Look forward to your attention
- Bloggers to recommend a series of documents: "Hands touch hands teaches you SpringBoot series chapter 97 section -16"
- This article is reproduced indicate the source (en must not turn only the text): letters Gebo off .