Separating the front and rear ends JWT Introduction

Brief introduction

Json web token (JWT), is a statement in order to pass between the network application execution environment based on open standards JSON (RFC 7519). The standard is designed to be compact and safe, commonly used to transfer the authenticated user identity information providers and service providers in the identity between facilitating access to resources from the server, you can also add some extra other business logic that must be Footnotes information. Of course, this standard can also be directly used for authentication may be encrypted.

JWT defined for a simple process to secure the object as JSON to transfer information between both self-contained for communication. JWT can use the HMAC algorithm is RSA public key or keys to be signed.

Features:

1, simple (Compact): smaller size, faster transmission means. JWT can be sent via URL, POST or HTTP head parameter.
2, self-contained (Self-contained): Payload contains all the necessary information about the user, avoiding the need for multiple queries the database.

1, the advantages of
(1) due to the versatility of Json, so JWT is to support cross-language, like Java, JavaScript, NodeJS, PHP and many other languages can be used.
(2) Because of the payload portion, JWT business logic may be stored other necessary non-sensitive information itself.
(3) ease of transport, the JWT configuration is very simple, small occupied bytes, so it is very easy to transport.
(4) It does not save session information in the server, so it is easy to extend the application of
2, safety-related
(1) should not store sensitive information in the payload section of JWT, because this is part of the client can decrypt part.
(2) protect the secret private key that is very important.
(3) If possible, use the HTTPS protocol, no! It is sure to use HTTPS!

And compare Session of the stored id

Session stored user id's biggest drawback is that Session is stored on the server side, it would take a lot of server memory, for larger applications may have saved many of the state. In general, large applications also need the help of some KV database and a series of mechanisms to achieve Session cache memory. The JWT way the user dispersed to the client, the server can significantly reduce the memory pressure. In addition to user id, you can also store other information associated with the user, for example, whether the user is an administrator, user groups, etc. are located. Although JWT has some way to make the server computing pressures (such as encryption, encoding and decoding), but these pressures probably not what it is compared in terms of disk storage.

scenes to be used:

• Verify
  the most common application of JWT. Once the user logs on, each subsequent request will include JWT. It will allow users to access the token allows routing, services and resources.
  Single sign-on is widely used today JWT's a feature, because the cost is small and easy to use across different domains.

• Information exchange
  JWT is a good way to secure transmission of information between the parties, because JWT can be signed (for example, using public / private key pair to sign). Further, since the head portion (header) and a payload (payload) compute the signature, you can also verify whether the content has not been tampered.

Structure Description

JWT comprises three parts separated by dots, which is (.):

• Head (header)
• Payload (payload)
• Signature (Signature)
  Thus, JWT typically looks as follows:
  

Header head

It contains header token type (i.e. JWT) and the use of encryption algorithms (e.g., HMAC SHA256 or RSA).

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

Then, with this JSON Base64 encoding, forming a first portion of the JWT.

Payload load

This is part of the payload comprising a statement (store specific information, such as a user ID). Statement is a statement about an entity (usually the user) and additional metadata. There are three types of statements:

• Declaration of
• Public statement
• Private statement

(1) Standard Specification Statement predefined inside several popular following statement (recommended not mandatory):

• iss: jwt issuer
• sub: jwt for the user
• aud: the receiving side jwt
• exp: jwt expiration time, the expiration date must be greater than the issue of time
• nbf: What time is defined before the jwt are not available.
• iat: jwt the issue of time
• jti: jwt unique identity, is mainly used as a one-time token, in order to avoid a replay attack.

{
    "iss": "lion1ou JWT",
    "iat": 1441593502,
    "exp": 1441594722,
    "aud": "www.example.com",
    "sub": "[email protected]"
}

The payload is then Base64 encoding to form a second portion of the token JSON Web.

Signature Signature

Who used to verify the sender's signature is usually JWT is and JWT not been tampered with during the transfer.

The first two parts are Base64-encoded, i.e., the front end can know the information decrypted JWT inside.
Signature is required header and payload encoded and we provide the key , then use the signature algorithm (HS256) header specified sign.

To create a signature part, must head (header), payload (payload), Key (secret), and the algorithm specified in the head. For example, if you want to use HMAC SHA256 algorithm, the signature will be created as follows:

Note: secret box of red on the map is stored on the server side, the issue generated JWT is also on the server side, secret is to be issued and JWT jwt verification, so it is your server's private key, in any scenario should not go showing. Once the client has learned the secret, it means that the client can be self-signed jwt up.

The signature process, is actually a sign of the head and load content, prevent content from being tampered with. If someone were to the head and load content after decoding modify, re-encoded signature combinations before last with the formation of new JWT, then the server will be judged on the signature and comes with JWT and load the new head formation the signature is not the same. If you want to sign the new head and load, the key used when you do not know the server is encrypted, then get out of the signature it is not the same.

note

Base64 is an encoding technique is reversible, so that our information is likely to be exposed. Therefore, in the JWT, which should not be added at any load sensitive data. In the example above, we transfer the user's User ID. This value is not actually what sensitive content, in general, is know is safe. But like the contents of a password can not be placed in the JWT. If the user's password in the JWT, then a malicious third party by Base64 decoding can quickly know the user's password.
Therefore, JWT is suitable for application to pass some non-sensitive information to the Web. JWT also often used to design user authentication and authorization systems, and even to achieve single sign-on Web applications.

use

1. By front-end Web form to send your user name and password to the back-end interface. This process is typically a HTTP POST request. The manner suggested by SSL-encrypted transmission (https protocol), thereby avoiding the sensitive information is sniffed.
2. After the rear end of the username and password verification is successful, another user id like as JWT Payload (load), which was signed and Base64 encoded splice head, respectively, forming a JWT. JWT is formed just like a xxxxx.yyyyy.zzzzz string.
3. JWT string as the rear end of a successful login returns the results back to the front. Front-end results can be saved on the return of localStorage or sessionStorage (on JWT store where it was said to the local store to store, it was said deposit cookie. On personal preference for local storage), delete saved when you exit sign in the front of JWT can .
4. When the front end of each bit JWT Authorization request into the HTTP Header (XSRF problem solving and XSS).
5. Check for the back-end, such as validation JWT existence. For example, check the signature is correct; check Token has expired; check whether the recipient is himself Token (optional).
6. After the back-end authentication using the user information contained JWT perform other logical operations, returns the corresponding results.

---

Attachment:

sign in

Session way to store user id, start a user's Session will be stored on a single server. For sites that multiple sub-domains, each subdomain will correspond to at least one different server, for example: www.taobao.com, nv.taobao.com, nz.taobao.com, login.taobao.com. So if you want to achieve after login.taobao.com login, in other sub-domain name can still get to the Session, which requires us to synchronize Session on multiple servers. JWT is no way to use the existence of this problem, because the user's state has been transferred to the client.