Why would you decouple your resource and login servers?

Question

As described on this link, OAuth specifies that a login server and a resource server should be decoupled. The idea is that if one of your resource servers gets hacked, no password data is lost. All login credentials that your applications use are on a single server. I get that this reduces the number of servers that hold login credentials. This way, if one of your applications gets hacked, you theoretically don't lose any login credentials. But is that all there is to it? What if the authentication server gets hacked? I can't tell from the OAuth specs what happens then. Aren't you putting all your eggs in one basket using this architecture?

Answer 1

This way, if one of your applications gets hacked, you theoretically don't lose any login credentials. But is that all there is to it?

No, an additional benefit (or possibly the main benefit) is that a resource owner can give temporary access to a subset of their resources to a client without giving away their credentials. From the document you linked:

For example, an end-user (resource owner) can grant a printing
service (client) access to her protected photos stored at a photo-
sharing service (resource server), without sharing her username and
password with the printing service. Instead, she authenticates
directly with a server trusted by the photo-sharing service
(authorization server), which issues the printing service delegation- specific credentials (access token).

The Beginner’s Guide to OAuth explains this a bit more in-depth.

What if the authentication server gets hacked?

That would be bad, but it's not any more likely than your resource server being hacked.

In fact, it is probably less likely, as an authentication server is less complex than a resource server and thus less open to the common web vulnerabilities (only very limited database queries, so only few chances for SQL injection; no or close to no user output, so less danger of XSS; no file upload; probably no danger of LFI/RFI; etc). There are of course still problems.

So the second benefit of OAuth is that it separates sensitive data that is relatively easy to handle from less sensitive data that is quite complex to handle, and thus less protected.

Aren't you putting all your eggs in one basket using this architecture?

You were doing that before as well. Now you at least have two baskets.

And the protocol doesn't seem to suggest that you should only ever have one authentication server for all of your application servers. So if you had multiple, separate application servers before, you can now have an authentication server for each of them (if the costs are worth the gain in security for you).

Answer 2

No, this does not put all your eggs in the same basket, it takes some of the eggs out of the security basket and puts them in your resource basket. Using more common security terminology, you are "reducing your attack surface".

The idea is that every bit of code you are running has potential vulnerabilities in it. (Obviously, we'd all like to deploy only perfect code, but the web is littered with victims of that optimism.) So instead we look at isolating damage in case the code has some vulnerabilities.

It's important to understand that not all servers are equal. When violated, some servers pose more risk to your organization than others.

What can be damaged if the attacker violates the resource computer? Well, they can access your resources. They might be able to gain a foothold in your network, but it depends on the vulnerability, how your servers are configured, what he finds, etc.

If the attacker violates the auth server, he has all your credentials, and can more easily violate every aspect of your systems by impersonating legitimate users. With this, he could go violate other servers in your environment, steal orders, or even reconfigure your system to intercept payments from clients.

Given that a violation of the auth server has the potential to do more overall damage to your organization, what you want to do is minimize the amount of code running on it, in order to reduce potential vulnerabilities. Hosting the resources on a different server is an easy way to reduce the attack surface on that critical server.