RESTful API identity Authentication Security Design

Rest is a software architecture style. The RESTful API is an HTTP protocol-based API and is a stateless transport. Its core is to understand all the APIs as a network resource. Encapsulates the state transitions (actions) of all clients and servers into the Method of HTTP requests.

You can read http://mengkang.net/620.html for details.

This article is mainly about RESTful API authentication security design.

There is no absolute security, the topic is very deep, the following are some of their own understanding, the level is limited, if there are errata, I hope you will correct.

Because the RESTful API is an HTTP protocol-based API, it is stateless, so as long as the user's identity is related to the request will be with the identity authentication information. (Most of the time the client does not know beforehand that an API will not be added to identity judgment, so we will generally choose each request with the authentication information, if any.) ）

Http Basic Authentication

Http Basic is a relatively simple way to authenticate. Add key values to Authorization:basic xxx (XXX is USERNAME:PASSOWRD base64 value) in the Http header.

For example, username is ZMK, password is 123456, and the request is as follows

Get/auth/basic/http/1.1host:xxxxxauthorization:basic em1rojeymzq1ng==

And Base64 decoding is very convenient, if you do not use Https, the equivalent is the account password directly exposed in the request.

High risk, the actual developer should use almost 0.

By the way the DIGEST certification, and BASIC certification is similar, and not suitable for the API design, the actual need two requests, the first request, the server side returned 401, and with the nonce value, and then the client re-use Username + password + nonce default MD After 5 requests again. The purpose of the HTTP request is to prevent only two requests, and there is no elevation of identity authentication.

Cookie + Session

I don't know if I should call it that, I just feel like a cookie and a session mechanism.

The principle is that when the client login is complete, to return a cookie to the client, the server control the session's validity period, each request with the value, and then the server side to do the verification, after exiting, the client notifies the service end to destroy the session, itself destroys the cookie. However, if the capture packet gets a cookie, it can spoof the request arbitrarily.

High risk, the actual development of the estimated use of a lot.

Api key + Security key + sign

Is our own every request for identity authentication method, if there is insufficient, please point out. It can be said to be a custom version of JWT.

The authentication logic here is:

1. User Login Returns a api_key and Security_key;

2. The client then security_key the client to exist;

3. To send a request, by Function2 encryption method, the five values are encrypted together to get a sign;

4. When sending a request, the value outside of Security_key will be removed, along with sign sent to the server side;

5. The server-side first verifies that the timestamp is valid, such as the server timestamp 5 minutes before the request is considered invalid;

6. Then verify the Sercurity_key according to Api_key;

7. Finally verify sign.

Do I need to add timestamp validation?

The above authentication logic in the encryption to get signed, the time stamp is added in order to some extent to block some invalid requests, can be omitted, can also be designed more stringent. If you want to prevent malicious API DDoS attacks, this step of validation is certainly not possible. More validation is required, such as user authentication, IP authentication, and so on. You can refer to the design of the GitHub API. It will be in the returned HTTP header information.

x-ratelimit-limit:5000x-ratelimit-remaining:4999

Represents the maximum number of times that an authorized user has called this interface for a time period of 5,000, remaining 4,999 times in that period. Of course, such validation, plus, will certainly have an impact on the execution efficiency of the code.

Do I need to add request_parameters to the algorithm that sign generates?

is not necessary, just for the authenticity of the request, reduce the forgery of the request, for example, if someone grabbed a packet to get an HTTP request, if the sign is not verified, then others can easily modify the parameters of the request, and the request will take effect.

The lesson of blood, a practical case of his own experience:

An interface that cancels a user's favorite tag, which sends a request_parameters like ids=1,2,3,4 to the server, then cuts it after the server ends up with those IDs, and then removes the user and the relationship of those tags from the User_tag table. A weekend, database server alarm, and according to our user habits, that time there is no traffic spikes, this alarm is not normal, is preparing to deal with the alarm ended, but after a period of time there is a user reaction they like the label has been deleted.

By querying the database for slow logs, it was found that there were many injected SQL.

DELETE from ' User_tag ' where uid=4385328 and tid=1 or 14=14;delete from ' User_tag ' where uid=4385328 and tid=1 or 91=91;

Originally did not do after the cut the ID does not do the digital verification, estimates the hacker is passes the Ids=1 OR 14=14,2,3, but a delete operation may time out, he has made many requests, is really enough ruthless.

Fortunately, the database also has timed packaged backups, and most of the users ' data is restored, while the vulnerability is fixed.

So if the request_parameters is also added to the signature, it reduces the possibility of forgery, but can not be eliminated, the perpetrators may not want to black you, but also very familiar with the reverse engineering, find our encryption algorithm implementation, still can be unknown legal signature, so we often say, The server can never trust that the client's request is secure and legitimate, and that it is not possible to omit the validation.

At the same time this (sign algorithm) also causes the API interface debugging cost, the API test tool must also have to implement that set of algorithms, or is set in the development environment does not do the validation. When we configure the development environment is the VPN even test server intranet, and then test, or the development environment is also the risk of being exploited.

Project Example Https://github.com/zhoumengkang/netty-restful-server

JWT

The process of using JWT (JSON Web Token) is as follows (image from official website)

Its authentication mechanism is also login, issue the key to the client, and then each time the client sends the request through the JWT algorithm rules to assemble JWT Auth Header, server side for authentication.

The principle of Web authorization authentication is original aim, all the same.

It's just a JWT, a set of authentication protocols. The format is Header. Payload. Signature. Like Xxxxx.yyyyy.zzzzz. The signature content is a Header + Payload + Secret encrypted by the HMAC SHA256 algorithm.

HMACSHA256 (  Base64urlencode (header) + "." +  Base64urlencode (payload),  secret)

Many of the requested key-value pairs can be placed inside the Payload. Full explanation request See the official introduction http://jwt.io/introduction/

Note that, according to the JWT protocol, there is only one secret to know who the user is, so in secret the value must be able to decode the user's ID.

While we customize the authentication protocol when the header feel is not necessary, the use of what algorithm can be defined beforehand. So we didn't choose this way, but the way it was.

A lightweight RESTful Api based on Netty's rigorous security validation serverhttps://github.com/zhoumengkang/netty-restful-server

From: http://mengkang.net/625.html

RESTful API identity Authentication Security Design