PHP Interface Token explanation

This article mainly and everyone to share the PHP interface token detailed, hope to help everyone. Let's take a look at the interface feature summary:

Interface Features Summary:

1, because of non-open, so all the interface is closed, only for the company's internal products effective;

2, because the non-open, so oauth that set of protocol is not feasible, because there is no intermediate user authorization process;

3, a bit of interface requires users to log in to access;

4, a bit of interface does not require users to log on to access;

PHP Tokens (Tokens)

For the above characteristics, mobile and server-side communication requires 2 keys, that is, 2 tokens.

The first token is for the interface (Api_token);
The second token is for the user (User_token);

Say first token (Api_token)

Its responsibility is to maintain interface access to the concealment and effectiveness, to ensure that the interface can only be used for their own people, how to do? The following ideas:
A random string is generated by the common properties owned by both the server side and the client, and the client generates the string, and the server generates a string to validate the client's string by the same algorithm.

Now the interface is basically the MVC pattern, the URL is basically restful style, the URL in the general format as follows:
http://blog.snsgou.com/Module name/Controller name/method name? parameter Name 1 = argument value 1& parameter Name 2 = argument value 2& parameter name 3 = parameter Value 3
The interface token generation rules are referenced as follows:
Api_token = MD5 (' module name ' + ' controller name ' + ' method name ' + ' 2013-12-18 ' + ' encryption key ') = 770fed4ca2aabd20ae9a5dd774711de2
One of the
1, ' 2013-12-18 ' is the time of the day,
2, ' encryption key ' is a private encryption key, the mobile phone needs to register an "interface user" account on the server, the system will be assigned an account and password, data table design reference as follows:
Field Name Segment Type Comment
client_id varchar (20) Client ID
Client_secret varchar (20) client (encryption) key

Service-side interface verification, PHP implementation process is as follows:

<?php   //1, get get parameter value   $module = $_get[' mod '); $controller = $_get[' ctl ']   $action = $_get[' act ']; $client _i D = $_get[' client_id '];   $api _token = $_get[' Api_token ');   2, according to the client passed client_id, query the database, get the corresponding Client_secret   $client _secret = Getclientsecretbyid ($client _id);   3, the server to regenerate a copy of Api_token   $api _token_server = MD5 ($module. $controller. $action  . Date (' y-m-d ', Time ()).  $client _secret);   4, the client passes over the Api_token and the server generated by the Api_token to proofread, if not equal, the validation fails if   ($api _token! = $api _token_server) {       exit (' Access deny ');  Access denied}//5, validation passed, return data to client    ?>

Say the second token (user_token)

Its role is to protect the user's user name and password multiple submissions, in case the password leaks.

If the interface requires a user to log in, the access process is as follows:
1, users submit "user name" and "password", to achieve login (conditions allow, this step is best to go HTTPS);
2, after the successful login, the server returns a User_token, the generated rule reference is as follows:
User_token = MD5 (' UID of user ' + ' unix timestamp ') = ETYE0FGKGK4CA2AABD20AE9A5DD77471FGF
The service side uses the data table to maintain the status of the User_token, and the table is designed as follows:
Field Name Segment Type Comment
user_id int User ID
User_token varchar (36) User Token
expire_time int Expiration Time (Unix timestamp)

(Note: Only the core fields are listed, other extensions!!!) ）

After the server generates User_token, return to the client (own storage), each time the client interface requests, if the interface requires users to log in to access, you need to send user_id and user_token back to the server, the service side to accept the 2 parameters, the following steps need to do:

1, the effectiveness of testing api_token;

2, delete the expired User_token table records;

3, according to user_id,user_token get table records, if the table record does not exist, directly return the error, if the record exists, then proceed to the next step;

4, update the expiration time of the User_token (delay, to ensure that the validity of continuous operation is not lost line);

5, return interface data;

The interface use cases are as follows:

Request Method: POST
Post parameters: title= I am the title &content= I am content
Return Data:

{       ' code ' + 1,//1: Success 0: Failed      ' msg ' = ' operation succeeded '//Login failed, no access to      ' data ' = []}

How to prevent token hijacking?

Token is sure to have a leaking problem. For example, I get your phone, copy your token out, and you can log in as your identity before it expires.
An easy way to solve this problem
1, when the storage of tokens for symmetric encryption storage, time to untie.
2, the request URL, time stamp, token three of the combination of salt signature, service-side check validity.
The starting point for both approaches is that it's easier to steal your stored data, and it's harder to disassemble your program hack your encryption and decryption and signature algorithms. However, it is not difficult to say that it is difficult, so after all, it is the practice of anti-gentleman.

Related recommendations:

Example method for implementing token in PHP

Token of the App interface

How to set up a applet URL and token