¿Por qué desacoplaría sus servidores de recursos e inicio de sesión?

  

De esta manera, si una de sus aplicaciones es hackeada, teóricamente   No pierdas ninguna credencial de inicio de sesión. Pero ¿es eso todo lo que hay?

No, un beneficio adicional (o posiblemente el beneficio principal) es que el propietario de un recurso puede dar acceso temporal a un subconjunto de sus recursos a un cliente sin entregar sus credenciales. Del documento que has vinculado:

  

Por ejemplo, un usuario final (propietario del recurso) puede otorgar una impresión
  Servicio (cliente) acceso a sus fotos protegidas almacenadas en una foto-
  servicio para compartir (servidor de recursos), sin compartir su nombre de usuario y
  Contraseña con el servicio de impresión. En cambio, ella se autentica
  directamente con un servidor de confianza para el servicio de intercambio de fotos
  (servidor de autorizaciones), que emite la delegación de servicios de impresión-   credenciales específicas (token de acceso).

La Guía para principiantes de OAuth explica esto un poco más a fondo.

  

¿Qué pasa si el servidor de autenticación es hackeado?

Eso sería malo, pero no es más probable que su servidor de recursos sea hackeado.

De hecho, probablemente sea menos probable, ya que un servidor de autenticación es menos complejo que un servidor de recursos y, por lo tanto, menos abierto a las vulnerabilidades comunes de la web (solo consultas de bases de datos muy limitadas, por lo que solo hay pocas posibilidades de inyección SQL; no o cerca a ninguna salida del usuario, por lo que hay menos peligro de XSS; no se carga ningún archivo; probablemente no hay peligro de LFI / RFI; etc.). Por supuesto, todavía hay problemas .

Entonces, el segundo beneficio de OAuth es que separa los datos confidenciales que son relativamente fáciles de manejar de los menos sensibles, que son bastante complejos de manejar y, por lo tanto, menos protegidos.

  

¿No estás poniendo todos tus huevos en una canasta usando esta arquitectura?

Tú también estabas haciendo eso antes. Ahora al menos tienes dos canastas.

Y el protocolo no parece sugerir que solo debas tener un solo servidor de autenticación para todos tus servidores de aplicaciones. Por lo tanto, si antes tenía varios servidores de aplicaciones separados, ahora puede tener un servidor de autenticación para cada uno de ellos (si los costos valen la ganancia de seguridad para usted).

No, esto no pone todos los huevos en la misma canasta, toma algunos de los huevos de la canasta de seguridad y los pone en su canasta de recursos. Al utilizar una terminología de seguridad más común, está "reduciendo su superficie de ataque".

La idea es que cada bit de código que está ejecutando tiene vulnerabilidades potenciales. (Obviamente, a todos nos gustaría implementar solo el código perfecto, pero la web está llena de víctimas de ese optimismo). Por lo tanto, consideramos el aislamiento de daños en caso de que el código tenga algunas vulnerabilidades.

Es importante entender que no todos los servidores son iguales. Cuando se violan, algunos servidores suponen un mayor riesgo para su organización que otros.

¿Qué puede dañarse si el atacante viola la computadora de recursos? Bueno, ellos pueden acceder a sus recursos. Es posible que puedan establecerse en su red, pero depende de la vulnerabilidad, la configuración de sus servidores, lo que encuentre, etc.

Si el atacante viola el servidor de autenticación, tiene todas sus credenciales y puede violar más fácilmente todos los aspectos de sus sistemas al hacerse pasar por usuarios legítimos. Con esto, podría violar otros servidores en su entorno, robar pedidos o incluso reconfigurar su sistema para interceptar los pagos de los clientes.

Dado que una violación del servidor de autenticación tiene el potencial de hacer más daño general a su organización, lo que quiere hacer es minimizar la cantidad de código que se ejecuta en ella, a fin de reducir las posibles vulnerabilidades. Alojar los recursos en un servidor diferente es una forma fácil de reducir la superficie de ataque en ese servidor crítico.