Classification and design of Token types in API interface design

In the actual site design we often encounter user data validation and encryption problems, if the implementation of a single point, if the data accurate, how to put replay, how to prevent csrf and so on

Among them, in all service design, it is inevitable to involve the design of token.

At present, based on token generation, we divide the token generation into two types.

1, based on the user/website, visible encryption request mode

2. Invisible encryption Request mode based on inter-server communication (API Token)

Among them, the Web page/app access is divided into the login state and non-login state two request differences.

(Non-login requests require users to randomly generate a unique and time-sensitive token when they visit the page, which is different on each request)

(The token will be saved for a certain amount of time in the login status, the token in the page will be identified as the user identity)

Although the two roles have some difference, but the principle of implementation is the same.

1, non-login status

Principle:

Non-login state, to prevent the server resources from being reused, we will add a step in the front page to establish the initial session process to ensure that the next critical request is not exploited.

This type of authentication is typically used for experience pages, such as: Video playback pages, project or feature display pages, etc.

Advantages:

The goal is to prevent tokens from being compromised, repeatedly requesting server resources (similar to the role of signature algorithms for chattering and video playback)

Disadvantages:

All front-end encryption can be cracked, need to confuse the specific JS, while adding HTTPS and source judgment

2. Login Status

Token for login status

The login token is generated by the server:

Encode (MD5 ({session}+{User information summary}+{timestamp) +timestamp)

　　

The Federated Redis refreshes the user logon duration and token validity duration. Redis sets the automatic expiration time.

Verification Method:

Decode (Token)->sign+timestamp

if (SIGN===MD5 ({session}+{User Information Digest}+{timestamp}) {
Xxxx
}

(To prevent weak language judgment logic, verify that PW and token are judged by the strong type = = =)

Log out: remove Redis key value

Single Sign-on: update information when re-login, user information summary unchanged, automatically refresh Redis token value and validity period

3, API Asymmetric encryption

Asymmetric encryption of the API is often used for requests between servers, each of which holds the private key and the public key. The API interface is often reflected in the "app_id,app_key| App_secret "

Token Generation algorithm:

    /** * Generate token * @param $user _info String * @param $app _key string App_key * @param $app _id int app_id * @return String*/     Public functionGenerate_access_token ($user _info,$app _key,$app _id)    {        $time= Time(); $sign=SHA1($time.$advertiser _id.$app _key); $token=Base64_encode("{$time},{$user _info},{$app _id},{$sign}"); return $token; }

Token parsing Method:

Decryption method of the timeliness of a one-minute verification, the actual project can be opened according to the circumstances of the invalid settings.

    /** * Parse token * @param $access _token * @return Array*/     Public functionAnalysis_access_token ($access _token)    {        $token _array=Base64_decode($access _token); $token _array=Explode(',',$token _array); $time=$token _array[0]; $user _info=$token _array[1]; $app _id=$token _array[2]; $sign=$token _array[3]; if($time< ( Time()-60) | |$time> ( Time() + 60) {call_back (1101, ' Access Token expire!token= '.$access _token); }        Global $third _platform_app_key;//App_id-app_key Correspondence Table        if(!isset($third _platform_app_key[$app _id]) {Call_back (1101, ' Access Token App ID error!token= '.$access _token); }        $app _key=$third _platform_app_key[$app _id]; $local _sign=SHA1($time.$user _info.$app _key); if($local _sign===$sign) {            return [                ' Access_token ' =$access _token, ' user_info ' =$user _info, ' time ' =$time, ' app_id ' =$app _id, ' app_key ' =$app _key,            ]; } Else{call_back (1101, ' Access Token sign error!token= '.$access _token); }    }

Token change requires that each request generate a new token to ensure the timeliness of the request

additionally: in order to enhance the integrity of API interface requests, we will also post-order summary validation of the requested content. (See details: open.taobao.com/docv2.htm?docid=101617&doctype=1)

Today's popularity to the end of this, thank you, you are welcome to leave a message to discuss.