blocks|key|240010|text|按照安全性/复杂性递增的顺序：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|240011|基本HTTP身份验证|240012|许多API库可以让你在里面构建它(比如Django中的Piston)，或者你可以让你的let服务器来处理它。Nginx和Apache都可以使用服务器指令通过简单的b64encoded密码来保护站点。它不是世界上最安全的东西，但它至少是一个用户名和密码！|240013|如果你使用的是Nginx，你可以像这样在你的主机配置中添加一个部分：|240014|auth_basic+"Restricted";
auth_basic_user_file+/path/to/htpasswd;|code-block|syntax|javascript|240015|(将其放入您的location+/块中)|offset|length|style|CODE|240016|文档：http://wiki.nginx.org/HttpAuthBasicModule|240017|您需要获取python脚本来生成该密码，并将输出放入一个文件中：http://trac.edgewall.org/browser/trunk/contrib/htpasswd.py?format=txt|240018|文件的位置并不重要，只要Nginx可以访问它。|240019|HTTPS|240020|保护从你的服务器到应用程序的连接，这是最基本的，可以防止中间人攻击。|240021|你可以用Nginx做到这一点，它的文档非常全面：http://wiki.nginx.org/HttpSslModule|240022|一个自签名证书就可以了(而且是免费的！)。|240023|API密钥|240024|它们可以是您喜欢的任何格式，但如果您需要，它们可以为您提供撤消访问权限的好处。如果您正在开发连接的两端，则可能不是完美的解决方案。它们通常在有第三方使用API时使用，例如Github。|240025|OAuth|240026|这里使用的是OAuth+2.0。虽然我不知道该规范的基本工作原理，但它是现在大多数身份验证(Twitter、Facebook、Google等)的事实标准。有一大堆的库和文档可以帮助你实现这些。也就是说，它通常用于通过请求第三方服务进行身份验证来验证用户身份。|240027|考虑到您在进行两端的开发，将您的API放在基本的HTTP+Auth后面并通过HTTPS提供它可能就足够了，特别是如果您不想浪费时间在OAuth上的话。|240028|entityMap|0|LINK|mutability|MUTABLE|url|http://wiki.nginx.org/HttpAuthBasicModule|1|http://trac.edgewall.org/browser/trunk/contrib/htpasswd.py?format=txt|2|http://wiki.nginx.org/HttpSslModule^0|0|0|0|0|0|7|A|0|3|15|0|0|W|1X|1|0|0|0|0|O|Z|2|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|1S|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|1T|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|1U|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|1V|8|@]|9|@]|A|$]]|$1|H|3|I|5|J|7|1W|8|@]|9|@]|A|$K|L]]|$1|M|3|N|5|6|7|1X|8|@$O|1Y|P|1Z|Q|R]]|9|@]|A|$]]|$1|S|3|T|5|6|7|20|8|@]|9|@$O|21|P|22|1|23]]|A|$]]|$1|U|3|V|5|6|7|24|8|@]|9|@$O|25|P|26|1|27]]|A|$]]|$1|W|3|X|5|6|7|28|8|@]|9|@]|A|$]]|$1|Y|3|Z|5|6|7|29|8|@]|9|@]|A|$]]|$1|10|3|11|5|6|7|2A|8|@]|9|@]|A|$]]|$1|12|3|13|5|6|7|2B|8|@]|9|@$O|2C|P|2D|1|2E]]|A|$]]|$1|14|3|15|5|6|7|2F|8|@]|9|@]|A|$]]|$1|16|3|17|5|6|7|2G|8|@]|9|@]|A|$]]|$1|18|3|19|5|6|7|2H|8|@]|9|@]|A|$]]|$1|1A|3|1B|5|6|7|2I|8|@]|9|@]|A|$]]|$1|1C|3|1D|5|6|7|2J|8|@]|9|@]|A|$]]|$1|1E|3|1F|5|6|7|2K|8|@]|9|@]|A|$]]|$1|1G|3|-4|5|6|7|2L|8|@]|9|@]|A|$]]]|1H|$1I|$5|1J|1K|1L|A|$1M|1N]]|1O|$5|1J|1K|1L|A|$1M|1P]]|1Q|$5|1J|1K|1L|A|$1M|1R]]]]

In order of increasing security / complexity:

<h2>Basic HTTP Auth</h2>

Many API libraries will let you build this in (Piston in Django for example) or you can let your webserver handle it. Both Nginx and Apache can use server directives to secure a site with a simple b64encoded password. It's not the most secure thing in the world but it is at least a username and password!

If you're using Nginx you can add a section to your host config like so:

<pre><code>auth_basic "Restricted";
auth_basic_user_file /path/to/htpasswd;
</code></pre>

(Put it in your <code>location /</code> block)

Docs: <a href="http://wiki.nginx.org/HttpAuthBasicModule" rel="noreferrer">http://wiki.nginx.org/HttpAuthBasicModule</a>

You'll need to get the python script to generate that password and put the output into a file: <a href="http://trac.edgewall.org/browser/trunk/contrib/htpasswd.py?format=txt" rel="noreferrer">http://trac.edgewall.org/browser/trunk/contrib/htpasswd.py?format=txt</a>

The location of the file doesn't matter too much as long as Nginx has access to it.

<h2>HTTPS</h2>

Secure the connection from your server to the app, this is the most basic and will prevent man in the middle attacks.

You can do this with Nginx, the docs for it are very comprehensive: <a href="http://wiki.nginx.org/HttpSslModule" rel="noreferrer">http://wiki.nginx.org/HttpSslModule</a>

A self-signed certificate for this would be fine (and free!).

<h2>API Keys</h2>

These could be in any format you like but they give you the benefit of revoking access should you need to. Possibly not the perfect solution for you if you're developing both ends of the connection. They tend to be used when you have third parties using the API, eg Github.

<h2>OAuth</h2>

OAuth 2.0 is the one to go with here. While I don't know the underlying workings of the spec it's the defacto standard for most authentication now (Twitter, Facebook, Google, etc.) and there are a ton of libraries and docs to help you get those implemented. That being said, it's usually used to authenticate a user by asking a third party service for the authentication.

Given that you doing the development both ends it would probably be enough to put your API behind Basic HTTP Auth and serve it over HTTPS, especially if you don't want to waste time messing around with OAuth.

blocks|key|242760|text|这里有一种不同的思考方式：|type|unstyled|depth|inlineStyleRanges|entityRanges|data|242761|让我们暂时假设您没有使用API。您的用户登录到应用程序，提供一些凭据，然后您给用户一个cookie或某种类似的令牌，您使用它来识别该用户已经登录。然后，用户请求一个包含受限信息(或创建/修改/删除它)的页面，因此您可以检查此令牌，以确保允许用户查看该信息。|242762|现在，在我看来，你在这里唯一改变的是信息传递的方式。不是将信息作为呈现的HTML传递，而是以JSON的形式返回信息并将其呈现在客户端。您对服务器的AJAX请求将携带与之前相同的登录令牌，因此我建议只检查该令牌，并以同样的方式将信息限制为“允许用户知道的内容”。|242763|你的api现在和你的登录一样安全--如果任何人知道访问API所需的令牌，他们也会登录到该站点，并有权访问所有信息。最好的一点是，如果你已经实现了登录，你就不需要做更多的工作了。|242764|像OAuth这样的系统的要点是提供这种“登录”方法，通常是从第三方应用程序或作为开发人员。对于iPhone或类似的应用程序来说，这可能是一个很好的解决方案，但那是未来的事情。API接受多个身份验证方法没有任何错误！|242765|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

Here's a different way of thinking about it:

Let's suppose for a moment that you're not using an API. Your user logs into the app, providing some credentials, and you give a cookie or similar token of some sort to the user, which you use to identify that user has logged in. The user then requests a page containing restricted information (or creating/modifying/deleting it), so you check that this token to ensure that the user is allowed to view that information.

Now, it sounds to me that the only thing you're changing here is the way that information is delivered. Instead of delivering the information as rendered HTML, you're returning the information as JSON and rendering it on the client side. Your AJAX requests to the server will carry that same logged-in token as before, so I suggest just checking that token, and restricting the information down to 'just what the user is allowed to know' in the same way.

Your API is now as secure as your login is - if anyone was to know the token necessary for accessing the api, they would also be logged into the site and have access to all the information anyway. Best bit is, if you've already implemented login, you've not really had to do any more work.

The point of systems such as OAuth is to provide this 'logging in' method, usually from a third party application and as a developer. This would potentially be a good solution for an iPhone app or similar, but that's in the future. Nothing wrong with the API accepting more than one authentication method!

blocks|key|3123483|text|到目前为止，这些答案解释得很好，但没有给出任何实际的步骤。我偶然看到了这篇博客文章，其中详细介绍了如何使用Node+%2B+Passport安全地创建和管理令牌。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|3123484|http://aleksandrov.ws/2013/09/12/restful-api-with-nodejs-plus-mongodb/|offset|length|3123485|entityMap|0|LINK|mutability|MUTABLE|url^0|0|0|1Y|0|0^^$0|@$1|2|3|4|5|6|7|M|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|N|8|@]|9|@$D|O|E|P|1|Q]]|A|$]]|$1|F|3|-4|5|6|7|R|8|@]|9|@]|A|$]]]|G|$H|$5|I|J|K|A|$L|C]]]]

The answers so far do a great job of explaining, but don't give any actual steps. I came across this blog post that goes into great detail about how to create and manage tokens securely with Node + Passport.

<a href="http://aleksandrov.ws/2013/09/12/restful-api-with-nodejs-plus-mongodb/">http://aleksandrov.ws/2013/09/12/restful-api-with-nodejs-plus-mongodb/</a>

blocks|key|3123511|text|对保护任何web应用程序有效的提示|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|3123512|如果你想保护你的应用程序，，那么你应该从使用HTTPS而不是HTTP开始，这将确保在你和用户之间创建一个安全的通道，防止嗅探来回发送给用户的数据，并有助于保护交换的数据的机密性。|3123513|您可以使用JWT+(JSON+Web+Token)来保护RESTful+API的安全，与服务器端会话相比，这有很多好处，主要的好处是：|3123514|1-更具伸缩性，因为您的API服务器不必为每个用户维护会话(当您有许多会话时，这可能是一个很大的负担)|3123515|2-+JWT是自包含的，并具有定义用户角色的声明，例如&他可以访问的内容&在日期和到期日期发布(在此之后，JWT将无效)|3123516|3-更易于跨负载均衡器处理&如果您有多个API服务器，因为您不必共享会话数据，也不必配置服务器将会话路由到同一服务器，只要带有JWT的请求命中任何服务器，就可以对其进行身份验证和授权|3123517|4-减少对数据库的压力，而且您不必经常为每个请求存储和检索会话id和数据|3123518|5-如果您使用强密钥对JWT进行签名，则JWT不能被篡改，因此您可以信任与请求一起发送的JWT中的声明，而不必检查用户会话&无论他是否被授权，您只需检查JWT&然后您就可以知道这个用户可以做什么了。|3123519|实现JWT的Node.js特定库：|3123520|许多库提供了创建和验证JWTs的简单方法，例如:在node.js中，最流行的方法之一是jsonwebtoken，对于验证JWTs，您可以使用相同的库，也可以使用express-jwt或koa-jwt+(如果您使用的是express/koa)|3123521|因为REST通常旨在保持服务器无状态，所以JWTs更符合这个概念，因为每个请求都是通过授权令牌发送的，授权令牌是自包含的(JWT)，而服务器不必跟踪用户会话，而不是让服务器有状态的会话，这样它就可以记住用户及其角色，然而，会话也被广泛使用，并有其优点，如果你想要的话，你可以搜索它。|3123522|需要注意的一件重要事情是，您必须使用HTTPS将JWT安全地交付给客户端，并将其保存在一个安全的地方(例如，本地存储中)。|3123523|您可以了解有关JWTs+from+this+link的更多信息。|3123524|entityMap|0|LINK|mutability|MUTABLE|url|https://www.npmjs.com/package/jsonwebtoken|1|https://github.com/auth0/express-jwt|2|https://github.com/koajs/jwt|3|https://jwt.io/^0|F|2|0|0|2H|0|0|1V|0|0|1F|0|0|1O|0|0|2J|0|0|10|0|0|2R|0|0|H|0|0|3C|17|C|0|28|B|1|2K|7|2|0|0|3X|0|0|1P|0|0|W|C|E|3|0^^$0|@$1|2|3|4|5|6|7|1H|8|@$9|1I|A|1J|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1K|8|@$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|H|3|I|5|6|7|1N|8|@$9|1O|A|1P|B|C]]|D|@]|E|$]]|$1|J|3|K|5|6|7|1Q|8|@$9|1R|A|1S|B|C]]|D|@]|E|$]]|$1|L|3|M|5|6|7|1T|8|@$9|1U|A|1V|B|C]]|D|@]|E|$]]|$1|N|3|O|5|6|7|1W|8|@$9|1X|A|1Y|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1Z|8|@$9|20|A|21|B|C]]|D|@]|E|$]]|$1|R|3|S|5|6|7|22|8|@$9|23|A|24|B|C]]|D|@]|E|$]]|$1|T|3|U|5|6|7|25|8|@$9|26|A|27|B|C]]|D|@]|E|$]]|$1|V|3|W|5|6|7|28|8|@$9|29|A|2A|B|C]]|D|@$9|2B|A|2C|1|2D]|$9|2E|A|2F|1|2G]|$9|2H|A|2I|1|2J]]|E|$]]|$1|X|3|Y|5|6|7|2K|8|@$9|2L|A|2M|B|C]]|D|@]|E|$]]|$1|Z|3|10|5|6|7|2N|8|@$9|2O|A|2P|B|C]]|D|@]|E|$]]|$1|11|3|12|5|6|7|2Q|8|@$9|2R|A|2S|B|C]]|D|@$9|2T|A|2U|1|2V]]|E|$]]|$1|13|3|-4|5|6|7|2W|8|@]|D|@]|E|$]]]|14|$15|$5|16|17|18|E|$19|1A]]|1B|$5|16|17|18|E|$19|1C]]|1D|$5|16|17|18|E|$19|1E]]|1F|$5|16|17|18|E|$19|1G]]]]

Tips valid for securing any web application

If you want to secure your application, then you should definitely start by using HTTPS instead of HTTP, this ensures a creating secure channel between you &amp; the users that will prevent sniffing the data sent back &amp; forth to the users &amp; will help keep the data exchanged confidential.

You can use JWTs (JSON Web Tokens) to secure RESTful APIs, this has many benefits when compared to the server-side sessions, the benefits are mainly:

1- More scalable, as your API servers will not have to maintain sessions for each user (which can be a big burden when you have many sessions)

2- JWTs are self contained &amp; have the claims which define the user role for example &amp; what he can access &amp; issued at date &amp; expiry date (after which JWT won't be valid)

3- Easier to handle across load-balancers &amp; if you have multiple API servers as you won't have to share session data nor configure server to route the session to same server, whenever a request with a JWT hit any server it can be authenticated &amp; authorized

4- Less pressure on your DB as well as you won't have to constantly store &amp; retrieve session id &amp; data for each request

5- The JWTs can't be tampered with if you use a strong key to sign the JWT, so you can trust the claims in the JWT that is sent with the request without having to check the user session &amp; whether he is authorized or not, you can just check the JWT &amp; then you are all set to know who &amp; what this user can do.

Node.js specific libraries to implement JWTs:

Many libraries provide easy ways to create &amp; validate JWTs, for example: in node.js one of the most popular is <a href="https://www.npmjs.com/package/jsonwebtoken" rel="nofollow noreferrer">jsonwebtoken</a>, also for validating the JWTs you can use the same library or use <a href="https://github.com/auth0/express-jwt" rel="nofollow noreferrer">express-jwt</a> or <a href="https://github.com/koajs/jwt" rel="nofollow noreferrer">koa-jwt</a> (if you are using express/koa)

Since REST APIs generally aims to keep the server stateless, so JWTs are more compatible with that concept as each request is sent with Authorization token that is self contained (JWT) without the server having to keep track of user session compared to sessions which make the server stateful so that it remembers the user &amp; his role, however, sessions are also widely used &amp; have their pros, which you can search for if you want.

One important thing to note is that you have to securely deliver the JWT to the client using HTTPS &amp; save it in a secure place (for example in local storage).

You can learn more about JWTs <a href="https://jwt.io/" rel="nofollow noreferrer">from this link</a>

I could do with some help on my REST API. I'm writing a Node.js app which is using Express, MongoDB and has Backbone.js on the client side. I've spent the last two days trying to work out all of this and not having much luck. I've already checked out:

<ul>
<li><a href="https://stackoverflow.com/questions/2676241/securing-a-rest-api">Securing a REST API</a></li>
<li><a href="https://stackoverflow.com/questions/4574868/securing-my-rest-api-with-oauth-while-still-allowing-authentication-via-third-pa">Securing my REST API with OAuth while still allowing authentication via third party OAuth providers (using DotNetOpenAuth)</a></li>
<li><a href="http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/" rel="nofollow noreferrer">http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/</a></li>
<li><a href="http://tesoriere.com/2011/10/10/node.js-getting-oauth-up-and-working-using-express.js-and-railway.js/" rel="nofollow noreferrer">http://tesoriere.com/2011/10/10/node.js-getting-oauth-up-and-working-using-express.js-and-railway.js/</a></li>
</ul>

I want to keep my backend and frontend as separate as possible so I thought about using a carefully designed REST API would be good. My thinking is that if I ever get round to developing an iPhone app (or something else like that), it could use the API to access data.

BUT, I want this to be secure. A user has logged into my web app and I want to ensure my API is secure. I read about OAuth, OAuth 2.0, OpenID, Hmac, hashes etc... I want to avoid using external logging in (Facebook/Twitter/etc) I want the registering and logging in to be on my app/server.

...but I'm still confused here. Maybe it's late at night or my brain is just fried, but I could really do with some steps on what to do here. What are the steps for me to create a secure API?

Any help, any information, any examples, steps or anything would be great. Please help!

Securing my Node.js app's REST API?

JSON Web Token

身份验证

负载均衡

RESTful API

服务器

数据库

MongoDB

路由

Django

OAuth

JSON

我需要一些关于REST API的帮助。我正在写一个Node.js应用程序，它使用Express，MongoDB，并在客户端有Backbone.js。在过去的两天里，我一直试图解决所有这些问题，但没有太多的运气。我已经检查过了：我想让我的后端和前端尽可能的分开，所以我想使用一个精心设计的REST API会更好。我的想法是...

问保护我的Node.js应用的REST API？
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问保护我的Node.js应用的REST API？EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问保护我的Node.js应用的REST API？
EN