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:
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.
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.
RELATED LINKS
- http://jwt.io/
- Https://github.com/firebase/php-jwt
- Https://scotch.io/tutorials/the-anatomy-of-a-json-web-token
- Https://github.com/auth0/jwt-decode
Token Little Note