Current location - Quotes Website - Signature design - How to design the security of RESTful API
How to design the security of RESTful API
For Web services based on WSDL and SOAP, we have security specifications such as WS-Security to guide the realization of security requirements, such as authentication, authorization and identity management. So, does RESTful API have a mature specification or implementation framework? How to ensure the security of RESTful API?

Kingsceo: Ensuring the security of RESTful API mainly includes three aspects:

A) verify the identity of the customer

B) Encrypt sensitive data to prevent tampering.

C) authorization after authentication

There are several common methods to authenticate clients:

Add signature parameters to the request.

1. Assign a key to each accessor and specify the signature calculation method. The signature parameter must be added to the visitor's request. This method is the simplest, but to ensure the safe storage of access keys, we should also pay attention to prevent replay attacks. Its advantage is easy to understand and implement, but its disadvantage is that it needs to bear the burden of keeping the key safely and updating it regularly, which is not flexible enough, and it is difficult to update the key and update the signature algorithm.

Use standard HTTP authentication mechanism.

HTTP basic authentication has low security and must be used with HTTPS. HTTP digest authentication can be used alone and has a moderate degree of security.

HTTP digest authentication mechanism also supports inserting user-defined encryption algorithm, which can further improve the security of API. However, in the Internet-oriented API, inserting custom encryption algorithm has not been widely used.

This method needs to ensure the safe storage of the triple information of "security domain-username-password" of the access party, and also pay attention to preventing replay attacks.

Advantages: based on standards, it has been widely supported (a large number of HTTP server-side and client-side libraries). The responsibility of server-side HTTP authentication can be undertaken by Web Server (such as Nginx), App Server (such as Tomcat) and security framework (such as Spring Security), which is transparent to application developers. HTTP authentication mechanism (RFC 26 17) embodies the design principle of "separating concerns" and keeps the visibility of operational semantics.

2. Disadvantages: The security of this mechanism based on simple user name and password cannot be higher than that based on asymmetric keys (such as digital certificates).

Use OAuth protocol for authentication.

The OAuth protocol is applicable to the case that external applications are authorized to access the resources of this site. Compared with HTTP digest authentication, encryption mechanism is more secure. It should be noted that OAuth authentication and HTTP digest authentication are not substitutes for each other, and their application scenarios are different. OAuth protocol is more suitable for providing authorization for end-user oriented API, such as obtaining Weibo information belonging to users and so on. If the API is not oriented to the end-user dimension, such as storage services such as Qi Niu Cloud Storage, this is not a typical application scenario of OAuth protocol.