How to design the security of restful APIs

Original: http://blog.csdn.net/ywk253100/article/details/25654101

Guidance: Security is a constant topic, for WSDL and SOAP-based Web Service, we have ws-security such security norms to guide the implementation of authentication, authorization, identity management and other security requirements. How to ensure the security of restful APIs.

Keywords: RESTful API API Security

with some of the features of a good restful API in front of you, this article continues to explore the security aspects of restful APIs.

InfoQ: Security is a constant topic, for WSDL and SOAP-based Web Service, we have ws-security security specifications to guide the implementation of authentication, authorization, identity management and other security requirements. So, is there any mature specification or implementation framework forRESTful APIs ? How to ensure the security of RESTful API?

Li Yu: secure restful APIs, including three main areas: A) authenticating the client b) Encrypt sensitive data and prevent tampering c) Authorization after identity authentication There are several common practices for authenticating clients: To add a signature parameter to a request 1. Assign a key to each access party and specify a method for calculating the signature. The signature parameter must be added to the request of the Access party. This is the simplest approach, but it is necessary to ensure the security of the access key, and also to guard against replay attacks. Its advantages are easy to understand and implement, the disadvantage is the need to bear the security key and regular update of the burden of the key, and not flexible enough to update the key and upgrade the signature algorithm is difficult. Use the standard HTTP authentication mechanism HTTP Basic authentication is less secure and must be used in conjunction with HTTPS. HTTP Digest authentication can be used alone, with a moderate level of security. The HTTP Digest authentication mechanism also supports the insertion of user-defined encryption algorithms, which can further improve the security of the API. However, inserting a custom encryption algorithm is not much used in Internet-facing APIs. This procedure needs to ensure the security of the security domain-user name-password ternary information, and also to guard against replay attacks. Pros: Based on standards, a wide range of support is available (large number of HTTP server side, client libraries). The responsibility for HTTP authentication on the server side can be assumed by Web server (such as Nginx), app Server (such as Tomcat), security framework (such as spring security), and is transparent to the application developer. The HTTP authentication mechanism (RFC 2617) is a good embodiment of the design principle of "separation of concerns" and preserves the visibility of operational semantics. 2. Cons: This type of security based on a simple user name + password mechanism cannot be higher than a mechanism based on an asymmetric key (such as a digital certificate). Using the OAuth protocol for identity authentication The OAuth protocol is used to authorize access to resources on the site for external applications. The encryption mechanism is more secure than HTTP Digest identity authentication. It is important to note that OAuth authentication is not a mutually replaceable relationship with HTTP Digest authentication, and that their application scenarios are different. The OAuth protocol is better suited to provide authorization for APIs that target end-user dimensions, such as obtaining Weibo information that is part of a user's profile, and so on. If the API is not intended for end-user dimensions, such as storage services like seven Cow cloud storage, this is not a typical scenario for OAuth protocols. 3. To encrypt sensitive data and to prevent tampering, common practices include: Deploying the SSL infrastructure (that is, HTTPS), the transmission of sensitive data is all based on SSL. Encrypt only partially sensitive data (e.g. card number + password for prepaid cards), and add a random number as the salt to protect against tampering with the data. Authorization after identity authentication is mainly controlled by the application. You should typically implement some kind of authorization mechanism based on role + user groups, there are many frameworks (such as spring Security), but most development teams prefer to implement the functionality themselves.

Li Jianye: I don't think security is a question restful api need to consider, in fact I think this is a two orthogonal question. Of course, if you use RESTFUL API to provide authentication, authorization, and identity management, it's a matter of both sides, but it doesn't seem to make any difference to the other styles of API design, and it doesn't deserve special attention. But at the specific design level, there seems to be some problem with the "positive intersection" of the two, because rest is an architectural style that is highly state-agnostic, and authentication and authorization are often based on third-party solutions, so there are often breaches of stateful constraints, and I don't have a particular idea of this place, Of course, this difficulty has little to do with the original problem. As for the ws-agreement, I am not very familiar with it and I am not quite able to participate in the discussion.

Jonathan Allen: for RESTful APIs, common security measures can continue to be used. For example, in order to prevent tampering, all parameters can be signed, in order to prevent replay attacks can add a one-time token in the request, or a short period of effective token, the content encryption can realize the data leakage ... For DDoS attacks, various HTTP traffic cleaning policies can continue to work because this is the basic HTTP request. In terms of authorization and authentication, OAuth 2.0 has been largely matured and has been widely used. If you can, access to a third-party account system is a good choice, such as Google and Facebook, of course, there are a few candidates at home.

Majun: Personally, the security of restful is divided into several levels, in the case of high security requirements, the security of the network layer can be ensured through the encryption protocol such as HTTPS, the application layer security can be authenticated by OAuth, and the access authorization for the resource, You can only rely on the application to implement it.

InfoQ: How do I version control restful APIs, share what you think is practical?

Li Yu: A relatively simple and practical approach is to insert the version number directly into the URI, which allows multiple versions of the API to run in parallel. Another option is to include the custom header information in the HTTP request, indicating the version number used. However, this practice is not friendly to the browser, simple to use the browser +html can not be tested.

Li Jianye: At present, the better way is to add version information to the URI design, other methods are not as practical as this.

Jonathan Allen: personally think the best version is no obvious version. When making changes to a published service, be as compatible as possible, including URIs, links, and the compatibility of different representations, and most crucially, you cannot break existing clients while scaling. For example, to change a parameter, you can choose to be compatible with both the old and the new inputs, or keep the old parameters intact, providing a new parameter that must be stated in the document and not recommended for new users to continue using the previous parameters. If you have to make incompatible changes, you can choose to mark different version numbers, and you can choose to add version information to the path or parameter. There are also ways to add HTTP headers, which are only slightly inconvenient when invoked, and recommend the first two methods.

Majun: Restfulapi version upgrade, as far as possible compatible with the previous version, to ensure that the original API is working properly, you can go through HTTP 301 to jump to new resources. Another practical approach is to keep the version number in the URL, while providing multiple versions for the client to use, such as v1.rest.com or rest.com/v1/.

Does the verb given in the infoq:http1.1 specification suffice for designing restful APIs? Do you expand your verbs in the actual project? Under what circumstances do I need to expand?

Li Yu: This question depends on how designers view and design resources. If the resource abstraction is doing well, any action on a resource can usually be mapped to a crud four category. CRUD Four categories are mostly complete for manipulating resources. The HTTP Get/post/put/delete four methods are sufficient for crud four categories of operations, and the mapping relationship is create-post/retrieve-get/update-put/delete-delete. We do not usually choose to create our own verbs, which will require more learning costs for the client developer. If there are too many operations defined on the resource, we will choose to split more resources.

Li Jianye: generally enough, sometimes some "not enough" scenario is because we did not design a reasonable resource, such as bulk operation. However, as previously stated, for some internal, traditional (and therefore model stable and known) systems, the API provider and caller will have their own fixed verb tables, and there is no need to rigidly adhere to them at this time. In addition, I do not recommend the extension of the verb, once the extension of the verb, in fact, has destroyed the "as little as possible prior information" *, then the extension of the verb and the cost of re-design verbs is not very different. Based on this consideration, I recommend that you keep the verb as long as possible, unless you want to redesign the verb table.

Jonathan Allen: in general, the usual HTTP verbs are sufficient, and there is no need to expand the verb itself. In fact, the most commonly used is get, POST, delete and put, while head, OPTIONS, trace is not very basic. If there is a moment to find the right verb, security power, such as the operation with get, the other can be used post, in the design of resources, a little consideration.

Majun: in my actual project, only the four verbs of post,put,delete,get are used.

InfoQ: What is the most valuable feature of the JAX-RS 2.0 specification released this May for the design of RSTFULAPI? What problems does it (are) used to solve?

Li Yu: Rest Development Framework Resteasy project leader Bill burke, wrote an article about jax-rs 2.0 last year. I agree with Bill's view in the article that the three most important parts of the jax-rs 2.0 additions are: A)  client api--is used to standardize the way the Jax-rs client is developed. The B)  server-side asynchronous http--is used to implement server-side push functionality without relying on inefficient polling methods. C)  filters and interceptors--is used to separate the concerns, separating the logic of authentication and logging from the business logic to better implement code reuse. The contents of these three parts of are useful for developers. Follow the JAX-RS specification for development to ensure server-side and client code portability.

Li Jianye: I personally focus on this part of the asynchronous API, mainly because streaming services are going to be more and more, and that will require a lot of this kind of support.

INFOQ: Can you recommend a useful RESTful API development framework for INFOQ readers and explain your referral rationale?

Li Yu: I will not answer this question in detail. Different programming languages have different rest development frameworks, and the level of support for rest is different. There is a wide range of requirements for developing restful APIs, and a wide range of development frameworks to choose from. Maintaining diversity is the foundation of a thriving ecological environment. Like Java there are many frameworks that support the JAX-RS specification of Jersey, Resteasy, Restlet, Apache CXF, and spring MVC, which does not support the JAX-RS specification. These frameworks are doing well at the moment. I have no inclination to choose the framework. The best practices for RESTful API design should be generic, rather than having to rely on a particular development framework.

Li Jianye: Sorry, I don't take this seriously, I can't recommend it, but I can explain why I don't have a cold on the Restful api frame. Rest, as an architectural style, has a significant impact on our system development, but these impacts are generally for schemas (such as state-independent) or designs (such as resource identification), so once a specific implementation is involved, the main work is basically over, At this point the development framework can do only the simplification of programming (in contrast, some framework can also play a role in guiding the design), and because the restful abstract verbs, so the implementation level and API specification related work is not much, then the value of the framework is even smaller. Of course, it's not possible to develop directly based on SERVLET/RAKC/WSGI, but the general programming language will provide some simple url route/match strategies that we can use. In addition, some frameworks can help us generate all the verb support, but this is not necessarily a good thing, I tend to achieve on-demand-the use of re-support, it is not necessary to pay much attention to the development framework of restful support.

Jonathan Allen: because I am a spring supporter, I also use spring in my work, so I tend to be more inclined to choose a frame spring  MVC (not that other frameworks are bad, there are some subjective elements here). If you must choose a different frame, you also have to choose a framework that is easy to integrate with spring. If spring has been used in the project, then there is no reason not to choose Spring mvc, given the current high mirror rate of spring in various projects, it is believed that SPRING MVC will generally be chosen. In the maturity model of Rest, the third tier is hateoas,spring. Spring hateoas sub-projects are currently available, and support for links, resources, and so on has been enhanced.

Majun: I am currently using spray in the actual project, which is an open source Rest/http toolkit and the underlying network IO package, built on Scala and Akka. Lightweight, asynchronous, non-clogging, actor-based, modular, and testable are spray features.

What is your expectation of the INFOQ:HTTP2.0 specification being developed?

Li Yu: My expectations include two aspects: what should and should not be done. The http/2.0 specification should do: 1. Remain compatible with the http/1.1 protocol. The meaning of compatibility is that both can coexist, and the client application can freely choose to use http/2.0 or http/1.1 based on server-side capabilities, and the selection process is transparent to the application.   2. Improve the efficiency of network transmission by improving the syntax of Operation semantic expression in HTTP protocol (as the unified interface of resources).   3. Better modularity, so that the implementation of the HTTP/2.0 protocol can be better modular. The application can select the appropriate modules as needed, rather than all or none.   4. Discard some of the rarely used portions of the http/1.1 protocol, such as using pipelines (pipelining) to send requests.   5. Add more verbs to accommodate scenes other than crud. The   http/2.0 specification should not do: the http/2.0 protocol should not use the underlying data encryption mechanism (that is, SSL) as a required option. The   http/2.0 protocol should not deviate from the constraints of the rest architectural style, especially to ensure the visibility of the operational semantics for the intermediate components.   In the above two aspects, roy fileidng once and Spdy Agreement designer Mike belshe have had a heated debate, see: Roy fielding Talk google  Spdy protocol

Li Jianye: Not much attention to this specification, do not know whether there will be support for the flow, I now know only the chunk way to do simple support, but the real flow needs to distinguish between the data channel and control channel-even the logical distinction, which directly to the rest style has a great impact , in view of the future development potential of streaming services, I am particularly looking forward to the industry's progress in this area.

Jonathan Allen: HTTP 2.0 is largely a reference to Google's Spdy, as far as I am concerned, first of all, I hope this specification can be compatible with HTTP 1.1, if users only know 1.1, then 2.0 can gracefully "downgrade"; Hope 2.0 can bring better performance, spdy in this aspect is improved, I hope HTTP 2.0 can build on; Finally, it is hoped that this specification will be accompanied by a best practice in finalizing it to properly guide people to use HTTP 2.0 appropriately.

Majun: not studied, estimated that even if it comes out, 1.1 has a very long life cycle, will not soon be replaced

How to design the security of restful APIs