After designing a nice REST + JSON API, how do you protect your API? At Stormpath, it took us 18 months to find best practices, put them into practice in the Stormpath API, and analyze their effects. This article explains how to protect the REST API.
Choosing the right security protocol industry-standard authentication protocol helps reduce the investment involved in protecting your APIs. You can also use a custom security protocol, but only for some very specific scenarios. The following is an overview of the pros and cons of several major protocols.
Basic Authentication W/tls Basic authentication is one of the simplest implementations in three general-purpose protocols (basic, Oauth 1.0a, Oauth2), mainly because of the time aspect, its implementation does not require additional libraries. Everything you need to implement Basic authentication is often included in the standard framework or language library you use. The problem with basic authentication is that it is too "basic", and it provides only the most basic security options for a common protocol. It does not provide advanced options for using this protocol, so you can only send user names and passwords that have been encrypted using BASE64.
never use a basic protocol without TLS (formerly known as SSL) encryption, because the combination of user name and password is easily cracked.
Oauth 1.0aOauth 1.0a is the safest of the three general-purpose protocols. Oauth1 is a widely used, tried-and-tested, secure, signature-based protocol. The protocol uses a set of cryptographic signature mechanisms to sign token keys, random numbers, and other use of request-based information.
the biggest advantage of Oauth1 is that you never transfer the token key directly over the network., it completely eliminates the possibility that some people will get a password during the transfer process. Oauth1 is the only protocol in three protocols that is safe to use without SSL (although you will still use SSL if you are sensitive to transmitting data). But this level of security comes at a cost: the generation and validation of signatures is a complex process. You must use a hashing algorithm with a series of strict steps. Nonetheless, this complexity is no longer a problem for you because every major programming language has a library to handle this for you.
Oauth2oauth2 sounds like an evolutionary version of Oauth1, but in fact it is a completely different protocol that attempts to reduce the complexity of authentication. The current version of Oauth2 has removed signatures, which means that you no longer need to use cryptographic algorithms to create, generate, and validate signatures. All of its cryptographic processing is now TLS and is required. Oauth2 is no longer a bunch of libraries like Oauth1, so integrating this protocol into your API can be more challenging. Last yearTranslator Note: This article was written in 2013), the first author of the Oauth2 Standard and the editor leave. Because of this instability of the normative committee, and because the default settings of Oauth2 are less secure than Oauth1 (without a digital signature it means that you cannot verify the integrity of the data content before and after transmission), so
for sensitive data applications we recommend Oauth1 compared to Oauth2.。
Oauth2 can be applied to lower-sensitivity scenarios, such as some social networks.
Customizations should avoid using custom licensing protocols, unless you do know exactly what you are doing and are fully aware of the myriad miscellaneous of digital signature encryption. Most organizations have no professional opinion on this, so we recommend oauth1.0a as a reliable alternative.
If you choose to take this potentially dangerous path, there is another reason to persuade you to look back: because it is custom, no one else can use it easily except you. You can use a custom protocol only when you are willing to give your REST API callers (Java,ruby,php,python, etc.) a client library to make your users use these protocols effortlessly. Otherwise, your API will be ignored by others.
What protocol have we chosen? In Stormpath, we are using a custom authorization protocol. It is similar to OAuth1, but it provides many enhancements (for example, a scheme that differs from the Oauth1,stormpath signature of the request body, so that the request body is not tampered with by calculating the signature). But again, this algorithm is only useful for clients that use the SDK that implements the algorithm. For other customers who do not use our SDK, we offer other general-purpose agreements.
Why use an API key instead of username/password Another technique we use is to replace the traditional username/password method with the generated API key. This decision is shown in the blog "Six main reasons to use the API key (and how to use it!") ), but it's also very important for API security, so here's a simple repetition:
Entropy API key/password is often a long string of random characters that is hard to guess. usernames/passwords are usually shorter, and using commonly used words is generally unsafe and prone to brute force or dictionary attacks.
The password reset issue is often reset. If you use a password as part of your API authorization scheme, the API access will fail after each password reset.
Speed best practices tell us to encrypt a password and then save it in a database to limit potential data leaks. This increases the load per request for user authentication. Unique API key authentication Skip the steps of this hash check so that your calls are speeded up. If you want to learn more about password storage, refer to the blog "How to Secure your password".
Save your API Key in Stormpath We encourage you to save the API key/password in an owner-only read-only file. The key/password pair is saved to the local file system after it is downloaded. The file ownership is then modified and only (the applied) user can read. This restricts the disclosure of the SDK when it uses the key.
Use of ID in order to reduce the security responsibility of your ID, you should set them to be opaque and globally unique. Do not use "1234", use "F6cd3459f9a39c9784b3e328f05be0f7". Disabling ordered numbers can help prevent hackers from "guessing" the next number, but also prevent the contention of ID values. In Stormpath, we use "Url62" when the UUID is generated. Strings that use the "URL security" are basically generated by a globally unique byte-array encoding. This allows us to safely use the ID in the URL without worrying about the coding problem.
Sessions and URLs avoiding the creation of a session for our REST API has become a good practice for Stormpath and has helped us improve API server performance. In addition to avoiding the overhead of session clusters (databases, Memcached, etc.), you can add additional machines to your API cluster to meet your increased user base needs.
When you implement a certification scheme (such as "who can see what" rules), try not to rely on a URL to protect your data or functionality. URLs change over time, so use the resource itself or its content as a starting point for your access control decisions.
Stormpath CTO Les also has a great video on REST security.
Original link: https://stormpath.com/blog/secure-your-rest-api-right-way/.
The right way to protect your REST API
