Token-based authentication for tokens in Java
Source: Reprint
Recently in the beginning of the project, involving the development of the interface between the server and Android, in this development process found that Android and the General browser, Android in each request will not bring the last request SessionID, Causes the server each time receives the Android sends the request access to create a new session to process, cannot through the traditional binding session to maintain the login state and the communication state.
Based on the traditional method can not judge the status of each request access to Android, so query information to understand the token, special identity card verification. The following is the online search information obtained, as a study summary information.
Tokens are special frames that control the site's possession of the media to differentiate between data frames and other control frames. Token actually said more popular point can be called code, before some data transmission, to first to check the password, different codes are authorized different data operation, the following we would like to introduce in detail about Token-based authentication tutorial
Learn about Token-based authentication recently and share it with everyone. Many large web sites are also used, such as Facebook,twitter,google+,github, and so on, compared to traditional authentication methods, Token is more extensible and more secure, it is very suitable for use in WEB applications or mobile applications. Token of the Chinese people translated into a "token", I think very good, meaning that you take this token, to get through some levels.
Traditional methods of authentication
HTTP is a stateless protocol, meaning that it does not know who is accessing the app. Here we regard the user as the client, the client uses the username and password to pass the authentication, but the next time the client sends the request again, it has to be verified again.
The solution is that when the user requests to log in, if there is no problem, we generate a record on the server, this record can explain the user who logged in, and then send this record ID number to the client, the client receives the ID number stored in the Cookie, The next time the user sends a request to the server, it can take this cookie so that the server verifies the information in the cookie to see if it can find the corresponding record on the server, and if so, indicates that the user has passed the authentication and returns the user's requested data to the client.
This is the session, we need to store the server as a login user generated session, these sessions may be stored in memory, disk, or database . We may need to periodically clean out the expired Session on the server side.
Token-Based authentication method
Using the Token-based authentication method, there is no need to store user login records on the server side. The approximate process is this:
Client Login with password request with username
The server receives the request to verify the user name and password
After verification is successful, the server will issue a token and send the token to the client.
The client receives tokens and can store them, such as in cookies or Local Storage.
The client needs tokens that are issued on the server each time it requests resources from the service side
The server receives the request and then verifies the Token that is in the client request and returns the requested data to the client if the validation is successful
JWT
There are a lot of ways to implement Token validation, and there are some standard methods, such as JWT, read: Jot, which means: JSON Web Tokens. The JWT standard Token has three parts:
Header
Payload
Signature
The middle is separated by dots and will be encoded using BASE64, so the real Token looks like this:
Eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9.eyjpc3mioijuaw5nagfvlm5ldcisimv4cci6ije0mzg5ntu0nduilcjuyw1lijoid2fuz2hhbyisimfkbwlu Ijp0cnvlfq.swyhtex_rqppr97g4j5lkxtabjecpejuef8aqkymajc
Header
The header part is mainly two parts, one is the Token type, the other is the use of the algorithm, such as the following type is JWT, the algorithm used is HS256.
{
"Typ": "JWT",
"ALG": "HS256"
}
The above content is encoded in Base64 form, so it becomes this:
Eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9
Payload
Payload inside is the specific content of tokens, some of which are standard fields, you can also add other required content. The following are the standard fields:
Iss:issuer, issuer
Sub:subject, Theme
Aud:audience, the audience.
Exp:expiration time, expiration
Nbf:not before
Iat:issued at, release time
JTI:JWT ID
For example, the following Payload, with the ISS issuer, and exp expiry time. There are also two custom fields, one is name and the other is admin.
{
"ISS": "Ninghao.net",
"Exp": "1438955445",
"Name": "Wanghao",
"Admin": true
}
After using BASE64 encoding, it becomes this way:
Eyjpc3mioijuaw5nagfvlm5ldcisimv4cci6ije0mzg5ntu0nduilcjuyw1lijoid2fuz2hhbyisimfkbwluijp0cnvlfq
Signature
The last part of JWT is Signature, this part of the content has three parts, first with the BASE64 encoded header.payload, and then encrypted with encryption algorithm, when the encryption to put in a Secret, which is equivalent to a password, This password is stored secretly on the server.
Header
Payload
Secret
var encodedstring = Base64urlencode (header) + "." + base64urlencode (payload);
HMACSHA256 (encodedstring, ' secret ');
It looks like this after processing is done:
Swyhtex_rqppr97g4j5lkxtabjecpejuef8aqkymajc
The last Token generated on the server and sent to the client looks like this:
Eyjhbgcioijiuzi1niisinr5cci6ikpxvcj9.eyjpc3mioijuaw5nagfvlm5ldcisimv4cci6ije0mzg5ntu0nduilcjuyw1lijoid2fuz2hhbyisimfkbwlu Ijp0cnvlfq.swyhtex_rqppr97g4j5lkxtabjecpejuef8aqkymajc
The client receives the token and stores it later, and carries the token when it sends the request to the server. This Token is received by the server, which is then validated and returned to the client after the desired resource.
Tokens in Java