Token-based authentication
Previous general by you already know about the session and cookie authentication, session authentication server needs to do a lot of work to ensure consistency and a session of storing session information, so modern web applications are more inclined to customers in the Certified Solution end direction, cookie authentication is based on a client's way, but the cookie disadvantages are also obvious, in the end what are the disadvantages can jump on one of the articles. That there a more eclectic approach it?
Some of them authentication information stored in the client, the key point is the safety of the verification, if we can solve the security problem of authentication information, can the authentication information stored in the client, the server completely certified status, so the server extensions together to a lot easier. Information on security solutions, is now common practice is the signature mechanism, such as authentication public micro-channel interface on signature-based mechanism.
Signature, others that only the sender of the information can not be forged to produce a piece of digital string, this string of numbers but also send a message to the authenticity of the sender information of a valid proof.
When the user successfully landing system and effective after successful authentication, the server will use some kind of mechanism to produce a string token, this token can contain a lot of information, for example, to the customer under the source IP, expiration time, user information, this string end, each request after the client are carrying this token, in fact, very free way to carry, either cookie or by other means can be, but the server must consensus can. Of course, here I do not recommend cookie. When the server receives a request for authentication token withdrawn (can verify the source IP, expiration time and other information), is allowed to operate if valid.
The token-based authentication is the modern Internet authentication method commonly used that it has what advantages do?
1. Support cross-domain access, Cookie is allowed to collapse domain access, which is on the Token mechanism does not exist, provided that the user authentication information transmitted via HTTP headers transmission.
2. Stateless: Token mechanism on the server to store session information is not required, because Token itself contains information about all logged-on user need only information stored in a cookie or a local state media clients.
3. Decoupling does not need to be bound to a specific authentication scheme. Token can be generated anywhere, as long as when your API is called, you can call the Token can generate.
4. The broader applicability: as long as it supports the http protocol client, you can use token authentication.
The server only needs to verify the security token, the logged-on user does not have to go to get information, because the information is already in the user's login token information.
6. Based on standardization: Your API can be standardized JSON Web Token (JWT) This standard has multiple back-end database (.NET, Ruby, Java, Python, PHP) adopted a number of companies and support (such as: Firebase , Google, Microsoft).
What are the disadvantages that have based authentication token it?
1. increase the amount of data transmitted over the network: As the token is stored in a large number of users and security-related information, so much larger than a simple cookie information transmission process need to consume more traffic, take up more bandwidth,
2. and all client authentication methods, like, if you want the server control token write-offs difficult, but also very difficult to solve the problem of hijacking the client.
3. Since the token information in the service side adds a data integrity verification operations, thus increasing the cpu overhead than the authentication session.
But, overall, based on the authentication token or the ratio session cookie and ways to have a great advantage. In the authentication token known in, jwt is an excellent solution, JSON Web Token (JWT) is an open standard (RFC 7519), which defines a compact, self-contained way, for as a JSON object securely transmit information between the parties. This information can be verified and trusted, since it was digitally signed.
A JWT is actually a string that consists of three parts, a head, a load signature.
head
A typical header consists of two parts: token type ( "JWT") algorithm and a name (such as: HMAC SHA256 or RSA, etc.).
{
"alg": "HS256",
"typ": "JWT"
}
Payload
Payload is part of a JSON object, used to store the actual data transfer is required. JWT provides for seven official field for the selection.
iss (issuer): Issuer
exp (expiration time): expiration time
sub (subject): Theme
aud (audience): Audience
nbf (Not Before): Effective time
iat (Issued At): The issue of time
jti (JWT ID): No.
In addition to the above fields, you can add any field you want, here is a reminder, due to the standard jwt, the information is not encrypted, so sensitive information is best not to add to json inside
{
"Name":"菜菜",
"Age":18
}
Signature
In order to get the signature section, you must have the encoded header, the encoded payload, a secret key (secret key that only the server knows), the signature algorithm is specified in the header, you can then sign them.
HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
After calculating the signature, the Header, Payload, Signature makes up a string of three parts, (.) Separated by a "point" between each section can be returned to the user. Need a reminder: base64 encoding is a way, not encryption.
基于token的认证方式，大体流程为：
1. 客户端携带用户的登录凭证（一般为用户名密码）提交请求
2. 服务端收到登录请求，验证凭证正确性，如果正确则按照协议规定生成token信息，经过签名并返回给客户端
3. 客户端收到token信息，可以保存在cookie或者其他地方，以后每次请求的时候都携带上token信息
4. 业务服务器收到请求，验证token的正确性，如果正确则进行下一步操作
这里再重复一次，无论是token认证，cookie认证，还是session认证，一旦别人拿到客户端的标识，还是可以伪造操作。所以采用任何一种认证方式的时候请考虑加入来源ip或者白名单，过期时间，另外有条件的情况下一定要使用https。