16

I have two enterprise servers which need to communicate in a secure way, and am comparing using SSL (with client/server certs to validate both sides) vs two-legged authentication using OAuth 2.0 (optionally with MAC tokens or JWT tokens).

Historically OAuth seems to have been created for a totally different purpose (the 3-legged case where a user is allowing a service to access some data somewhere), and although two-legged is now integrated into the OAuth 2.0 spec, from what I have seen two-legged OAuth 2.0 doesn't seem to offer much additional protection over SSL.

The only point I can think of is that OAuth is potentially easier to configure than SSL, and it is easy to make mistakes with things like accepting bad SSL certs which can compromise security. However I am not sure if this is reason enough to go with OAuth.

Note that I mention these as separate options, but I think using OAuth would probably entail using it on top of HTTPS/SSL, so both would be used.

Is there any real advantage of using OAuth 2.0 two-legged scheme for server-to-server communication (no user involved)?

Note: I did find a a somewhat similar post here, but that is quite old but I don't feel that gave a satisfactory answer on this matter.

Community
  • 1
  • 1
Locksleyu
  • 5,192
  • 8
  • 52
  • 77

3 Answers3

26

Apologies if you already know this but it isn't clear in your post.

OAuth and SSL\TLS are two separate layers of the OSI model. OAuth is for authentication and is at the top in Layer 7 while SSL\TLS is for transport security in layer 4. It's easy to confuse SSL with client certificates because they both use PKI.

You are correct in your understanding of OAuth...it is used for authorizing individuals not organizations\servers. 2-legged OAuth is a term that is thrown around which encompass various alternate OAuth flows, all of which do not follow a standard.

In my opinion, you want to use client certificates to secure your server-server communication...all that is really required is a single x509 certificate that can be used as both SSL (transport security) and client certificate (authorization); although using 2 certificates is the norm.

SKYWALKR
  • 612
  • 4
  • 6
  • 4
    Thanks for the response. To be clear, by '2 legged' I meant 'client credentials' grant type which I believe is documented in OAuth 2.0 protocol spec. My question is that, assuming I am using SSL with proper client/server certs to identify each machine, what value would using OAuth (2 legged or similar) on top of that to authorize the servers to one another (assuming there is no user involved). Thanks – Locksleyu Apr 20 '15 at 12:45
4

I'll respond to this comment:

My question is that, assuming I am using SSL with proper client/server certs to identify each machine, what value would using OAuth (2 legged or similar) on top of that to authorize the servers to one another (assuming there is no user involved). Thanks – Locksleyu

Summary: I wouldn't bother doing both.

Details: 2-legged OAUTH is only as secure as the consumer secret is. Similarly mutual auth SSL is only as secure as the private key. I assume that you'll be storing these in some encrypted store on each server. As both are stored in the same place I see no additional security that comes from adding OAUTH.

Now if you are considering a choice between mutual auth SSL and standard SSL with authentication, perhaps OAUTH can play a role there. I would go with whichever of those options seems easier. So if you have an OAUTH system in place and can easily add server auth to it, perhaps that's the way to go. Otherwise, just go with mutual auth SSL. It tends to be a bit of a hassle to configure but works well and quickly once set up.

Neil Smithline
  • 1,526
  • 9
  • 21
0

To answer your question "what value would using OAuth (2 legged or similar) on top of that to authorize the servers to one another (assuming there is no user involved)."

You may refer below

https://salesforce.stackexchange.com/questions/93887/mutual-authentication-two-way-ssl-oauth

Shweta
  • 1