Token based authentication

Traditional authentication system

1. The user enters the user name and password in the login domain , Then click log in
2. After the request is sent , Verify the legitimacy of users by querying the database at the back end . If the request is valid , Use the information obtained in the database to create a session, Then return this in the response header session Information about , The purpose is to put this session ID Store in browser
3. The restricted back-end server in the access application provides this session Information
4. If session The information is valid , Allow users to access restricted back-end servers , And the rendered HTML Content return
   

shortcoming

1. Cannot share the created by the server on the mobile side session and cookie
2. stay web End rendered HTML The page is returned , At the mobile end, the response needs to contain something similar JSON perhaps XML Things that are

be based on token Certification of

1. The user enters the user name and password in the login form , Then click log in
2. After the request is sent , Verify the legitimacy of users by querying the database at the back end . If the request is valid , Use the information obtained in the database to create a token, Then the information of this is returned in the response header , The purpose is to put this token Stored in the browser's local storage
3. It is provided every time a request to access the restricted back-end server in the application is sent token Information
4. If you get it from the request header token It works , Allow users to access restricted back-end servers , And back to JSON perhaps XML

advantage

No return session perhaps cookie, And we didn't return any HTML Content , That means we can apply this architecture to all clients of a particular application

token Transmit through the request header , Instead of storing authentication information in session or cookie in , This means statelessness , You can send from any one of them HTTP The requesting terminal sends a request to the server

JWT

JWT representative JSON Web Token, It is a kind of authentication header token Format . This token It helps you to transfer information between two systems in a safe way . There are three parts ：header,payload,signature

header yes token Part of , For storage token The type and encoding of , It is usually used base-64 code

payload Contains information , You can store any kind of information , For example, user information , Product information, etc , They all use base-64 Store by encoding

signature It includes header,payload And the key , The key must be securely stored on the server

---

token Validation process and classification

1、token Verify the basic process

be based on token Authentication method for , There is no need to store the user's login record on the server , The basic process is as follows ：
The client uses the user name and password to request login ;
The server receives the request , Verify user name and password ;
Verify success , The server will issue a token, Put this token Send to client ;
Client received token, Store it （Cookie、Loacal Storage、session storage）;
Every time the client requests resources from the server , It needs to be signed and issued by the server token;
The server receives the request , Verify the... In the request token, If the validation is successful , Return the requested data to the client .

2、Token( token ) classification

Interface specific api_token
For users user_token

(1)、 Interface token Production rules

api_token = md5 (' Module name ' + ' The controller, ' + ' Method name ' + ' year - month - Japan ' + ' Encryption key ')

(2)、 user token Production rules

user_token = md5(' User uid' + 'Unix Time stamp ')