OAuth进行服务器到服务器API安全性 [英] OAuth for Server to Server API Security
问题描述
所以这几天我都走遍了API安全最佳实践或技术网络，专门为被访问的直供从服务器到服务器（服务器到服务器）的API。似乎有许多不同的意见，而且很难将它们整合到一个可行的思路。
据许多，OAuth是要走的路。依赖于是否希望不使用安全套接字协议，选择是要么OAuth的1.0A或分别的OAuth 2.0。
关于OAuth的，我的理解是OAuth的1.0A主要关心的是请求的数字标牌，而OAuth 2.0用户依赖于底层的HTTPS来保证完整性。所以我是安全做出如下假设？
的假设：的如果使用HTTPS，一是不需要使用HMAC或任何形式的数字签名，以prevent重放攻击，中间人攻击，并保持正直。
这仍然留下授权，其中的OAuth通过交换令牌管理。但为什么这么复杂？我可以，例如，给所有服务器（私人消费者）全球唯一的用户名和秘密，使得每一个请求与秘密，用户名和请求参数的一些散签署？
这个，据我所知，意味着授权和认证。认证是通过哈希的确认进行管理，并禁止授权，因为，重要的是，每个服务器有相同的权限，以自己的的的资源。
因此，什么设计API时严格用于服务器到服务器（或2条腿）的沟通是最好的方法呢？是安全简单地使用HTTPS，然后签订个性化的散列每个请求，这意味着认证，授权，也无需需要保持状态/会话。
我可以理解，符合标准的就是开发人员编写code消费服务，和一般的网络文化，所以adherance一些子集的OAuth的娓娓动听受益;我只是不知道这是否是在这里需要。
假设你有一个已经与系统S2的信任关系系统S1。什么的OAuth确实是提供一种机制，使S1可给予S3访问到S2。也就是说，S3可以获准作用在S2中，使用S1的权限的某些部分。为此，它会在S1拥有的控制的一种方式。
问：我可以，例如，给所有服务器（私人消费者）全球唯一的用户名和秘密
答：当然，你可以做到这一点。如果你有你想跟每个系统的用户名和密码独特的，那么你有没有必要的OpenID OAuth的或的。但是，这会变得非常难以管理。 OAuth的可以让你有一个系统上的一个秘密，并授权任何数量的基于一个秘密的其他系统。这就是它存在的唯一理由。
如果你看一下OAuth的呢，就是它基本上使得一个新的独特的共享秘密（称为令牌，但你也可以把它叫做一个密码，如果你喜欢）为每个类型的访问给予了。该唯一秘密S2所产生的，而是从S1传递到S3，并且可以用作用于访问S2密码由S3。这是S2是控制的权限。该OAuth的做的唯一一件事就是让令牌S3。这消除了需要设置一个密码，并进行手动系统之间需要。
当你谈论两足通信的问题是：怎么共享的秘密得到它们之间建立？如果您手动（即物理上进行），并设置了密码，这两个系统，那么你有没有必要的OAuth。但是，这是一个很大的麻烦，如果你有很多的系统。 N个系统将需要（N *（N-1）/ 2）的密码。
通常你想要做的，就是让一台服务器充当一个认证服务器，每个服务器都有到信任关系。然后，您使用OAuth授权任何其他两个服务器之间的任何互动。这是复杂的意义所在。
一旦你的服务器之间的基本信任关系，你可以在那个标志请求顶部或签署相应处理（不可抵赖性）。
在设计一个服务，你需要考虑访问可能会被给出了方法。例如，你想有时间限制的访问，这将是很好的只有7天？将要进行只读可用的访问？这会给该种访问S2的S1选项它给S3。
让我说明用一个具体的例子：雪是好的，愿与您去滑雪。该滑雪场是开放的，但所有的钱是存在银行里。你想要做什么，是授权的滑雪场，从您的银行帐户中提取资金。你不想给你所有的钱给滑雪场。你并不会因为你的密码完全信任他们。因此，不是，你先联系银行，并安排一个权限撤回资金的具体数额。这是一个象征psented重新$ P $。然后，传递令牌滑雪场。使用该令牌，该滑雪场是能够收回指明资金量。总是为负责守卫您的资金，这是定义种类的交易，你也许可以设置权限的银行。 OAuth是仅仅是传递令牌，安全的标准方法。
So the past few days I have scoured the internet for API security 'best practises' or techniques, specifically for APIs that are accessed directry FROM a server TO a server (server-to-server). There seems to be many varied opinions, and it's hard to consolidate them into a workable idea.
According to many, OAuth is the way to go. Depending on whether one wishes to not use a secure socket protocol, the choice is either OAuth 1.0A or OAuth 2.0, respectively.
Regarding OAuth, my understanding is that OAuth 1.0A main concern is the digital signage of requests, whereas OAuth 2.0 relies on the underlying HTTPS to guarantee integrity. So am I safe to make the following assumption?
Assumption: If using HTTPS, one does not need to use HMAC or any form of digital signature to prevent replay attacks, man in the middle attacks and to maintain integrity.
This still leaves authorization, which OAuth manages via an exchanged token. But why is it so complex? Can I, for example, give all the servers (private consumers) globally unique usernames and secrets, such that each 'request' is 'signed' with some hash of the secret, username and request parameters?
This, as far as I can tell, implies authorization and authentication. Authentication is managed by the confirmation of the hash, and authorization is prohibited because, critically, every server has the same privileges to their own resources.
As such, what's the best approach when designing an API strictly for server-to-server (or "2-legged") communication? Is it safe to simply use HTTPS, and then sign each request with a personalized hash, implying authentication, authorization and also not requiring the need to maintain state/sessions.
I can understand that conformity to a standard is a benefit to developers writing code to consume the service, and the web culture in general, so adherance to some 'subset' of OAuth sounds appealing; I am just not sure if it's required here.
Assume you have system S1 that already has a trust relationship with system S2. What OAuth does is to provide a mechanism so that S1 can give S3 access to S2. That is, S3 can be given permission to act on S2, using some part of the permissions of S1. It does this in a way that S1 has control of.
Q: "Can I, for example, give all the servers (private consumers) globally unique usernames and secrets" A: Of course you can do this. If you have username and unique password with every system you want to talk to, then you have no need of OpenID or OAuth. But this becomes very hard to manage. OAuth allows you to have one secret on one system, and authorize any number of other systems based on the one secret. That is the only reason it exists.
If you look at what OAuth does, is that it basically makes a new unique shared secret (called a token, but you can also call it a password if you like) for each kind of access to be given out. That unique secret is generated by S2, but passed from S1 to S3, and can be used as a password by S3 for accessing S2. It is S2 that is "controlling" the access. The only thing that OAuth does is get the token to S3. This eliminates the need to set up a password, and manually carry it between the systems.
When you talk about a "two legged" communications, the question is: how did the shared secret get set up between them? If you manually (i.e. physically carried) and set up both systems with password, then you have no need for OAuth. But that is a lot of trouble if you have a lot of systems. N systems would need (N*(N-1)/2) passwords.
Normally what you want to do, is to have one server act as an "authentication server" and every server has a trust relationship to that. Then, you use OAuth to authorize any interactions between any two other servers. That is what the complexity is all about.
Once you have the basic trust relationship between servers, you can on top of that sign requests or sign responses (for non-repudiation purposes).
When designing a service, you need to think about ways that access might be given out. For example, do you want time-limited access that would be good for only 7 days? Would you want to make "read-only" access available? This will give S1 options on the kinds of access to S2 that it gives to S3.
Let me illustrate with a specific example: Snow is good, and you would like to go skiing. The ski area is open, but all your money is in the bank. What you want to do, is to authorize the ski area to withdraw funds from your bank account. You don't want to give all your money to the ski area. You don't trust them with your complete password. So instead, you first contact the bank, and arrange for a "permission" to withdraw a specific amount of money. This is represented by a token. You then pass that token to the ski area. Using that token, the ski area is able to withdraw the specified amount of funds. The is always responsible for guarding your funds, and it is the bank that defines the kinds of transactions you might be able to set up permissions on. OAuth is just a standard way to pass the token around, securely.
这篇关于OAuth进行服务器到服务器API安全性的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
