Perché dovresti disaccoppiare le tue risorse e i server di login?

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, un ulteriore vantaggio (o forse il vantaggio principale) è che il proprietario di una risorsa può concedere l'accesso temporaneo a un sottoinsieme delle sue risorse a un cliente senza fornire le proprie credenziali. Dal documento che hai collegato:

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).

La Guida per principianti di OAuth spiega un po 'più in profondità.

What if the authentication server gets hacked?

Sarebbe male, ma non è più probabile che il tuo server delle risorse venga violato.

In realtà, è probabilmente meno probabile, poiché un server di autenticazione è meno complesso di un server di risorse e quindi meno aperto alle vulnerabilità web comuni (solo query di database molto limitate, quindi poche possibilità di SQL injection; no o close nessun output dell'utente, quindi meno pericolo di XSS, nessun caricamento di file, probabilmente nessun pericolo di LFI / RFI, ecc.). Ovviamente ci sono ancora problemi .

Quindi il secondo vantaggio di OAuth è che separa i dati sensibili che sono relativamente facili da gestire da dati meno sensibili che sono abbastanza complessi da gestire e quindi meno protetti.

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

Lo stavi già facendo prima. Ora hai almeno due cesti.

E il protocollo non sembra suggerire che si dovrebbe sempre avere un solo server di autenticazione per tutti i server delle applicazioni. Quindi, se prima disponevi di più server di applicazioni separati, ora puoi avere un server di autenticazione per ognuno di essi (se i costi valgono il guadagno di sicurezza per te).

No, questo non mette tutte le tue uova nello stesso paniere, toglie alcune delle uova dal paniere di sicurezza e le mette nel tuo cesto delle risorse. Usando una terminologia di sicurezza più comune, stai "riducendo la superficie di attacco".

L'idea è che ogni bit di codice che stai utilizzando abbia potenziali vulnerabilità al suo interno. (Ovviamente, vorremmo tutti implementare solo il codice perfetto, ma il web è pieno di vittime di quell'ottimismo.) Quindi, invece, consideriamo i danni isolati nel caso in cui il codice abbia delle vulnerabilità.

È importante capire che non tutti i server sono uguali. Quando vengono violati, alcuni server rappresentano un rischio maggiore per la tua organizzazione rispetto ad altri.

Cosa può essere danneggiato se l'utente malintenzionato viola il computer delle risorse? Bene, possono accedere alle tue risorse. Potrebbero essere in grado di prendere piede sulla rete, ma dipende dalla vulnerabilità, dalla configurazione dei server, da ciò che trova, ecc.

Se l'utente malintenzionato viola il server di autenticazione, ha tutte le credenziali e può violare più facilmente ogni aspetto dei sistemi impersonando utenti legittimi. Con questo, potrebbe andare a violare altri server nel tuo ambiente, rubare ordini o persino riconfigurare il tuo sistema per intercettare i pagamenti dai client.

Dato che una violazione del server di autenticazione ha il potenziale per fare più danni complessivi alla tua organizzazione, ciò che vuoi fare è ridurre al minimo la quantità di codice in esecuzione su di esso, al fine di ridurre potenziali vulnerabilità. Ospitare le risorse su un server diverso è un modo semplice per ridurre la superficie di attacco su quel server critico.