OAuth for Server to Server API Security

Question

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.

Answer 1

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.

Answer 2

What you've described as solution called "using client certificates for HTTPS communication" or "mutual SSL" - server presents its certificate with domain and client presents certificate somehow identifying itself. Works well for server-to-server cases.

This approach indeed allows to authenticate servers/users in secure and standard way. Your server that receives incoming requests will be able to make authorization decisions based on certificate presented by caller. Calling servers will need to either register they own certificates with your service or obtain your predefined certificates to call your service.

This approach works for cases where you can properly control distribution of client certificates or server accepts certificates obtained in some external way. If you control both ends of communication (i.e. securing traffic between components of your own multi-tiered system) than this approach is one of simplest.