È una questione di separazione delle preoccupazioni . In un caso, un provider di identità dedicato (IDP) esegue l'autenticazione e fornisce un token di accesso, che viene verificato da tutte le applicazioni Web prima che un utente (o un'applicazione) possa eseguire un'operazione. Nell'altro caso, ogni applicazione Web deve eseguire tale autenticazione (anche se condivide lo stesso codice base).
Le implicazioni sono importanti esp. per il consumo del codice:
- Se esiste un solo fornitore di identità, un utente (o il codice che consuma) verrà in genere autenticato una sola volta e il token di accesso potrà quindi essere fornito a tutte le applicazioni Web necessarie. Ciò consente il Single Sign-On (SSO) da implementare su più domini (si consideri il caso in cui un utente accede una volta a Facebook e quindi non deve fornire le credenziali per ogni sito che utilizza l'autenticazione FB.)
- Dato che esiste un IDP, tutta l'esperienza utente in merito agli accessi è molto più facile da gestire. Ad esempio, un utente accede a un'applicazione Web, reindirizza all'IDP per accedere. I casi come l'utente che dimentica il nome utente, o la password, o hanno qualche prerequisito mancante sulla loro macchina possono essere gestiti da questo servizio comune. Nel caso di ogni applicazione Web che fa ciò, in qualche modo l'esperienza dell'utente di autenticazione deve essere esposta attraverso ogni applicazione web, che è fattibile, ma più difficile da gestire.
- Esistono già protocolli consolidati che è possibile utilizzare per tali scenari (ad esempio OAUTH ), il che significa che è possibile utilizzare un IDP esterno (ora o in futuro) che supporta gli stessi protocolli senza cambiare la tua applicazione molto.
- Dal momento che le specifiche di tali protocolli sono standardizzate, c'è una maggiore possibilità che si ottenga la sicurezza, dal momento che importanti parametri sono forzati nel protocollo (sebbene ci siano ancora vulnerabilità che è necessario gestire, ad esempio OAUTH è soggetto a CSRF attacca come esempio).
Il vantaggio di ciascuna applicazione Web che esegue l'autenticazione è:
- L'implementazione iniziale di solito costa meno, perché non si ha a che fare con la creazione di token di accesso e il loro trasferimento e convalida. Una volta passate le credenziali a un'applicazione Web, è possibile effettuare una chiamata interna a una libreria (o servizio) comune per convalidare le credenziali. Di solito, i framework di sviluppo web forniscono già alcune funzionalità per ottenerli, quindi il costo è spesso molto basso.
- Se tutte le tue app sono su un dominio (e puoi utilizzare i cookie per il Single Sign-On), è un'esperienza utente molto più pulita (ma non appena hai due o più domini, l'esperienza utente diventa difficile specialmente quando non esiste un unico accesso.)
Amazon, Microsoft, Facebook, Google, ecc., tutti utilizzano un servizio dedicato perché i professionisti sono molto più importanti per i loro utenti e utilizzano applicazioni rispetto al costo di implementazione. Inoltre, dispongono di team dedicati che lavorano su funzioni di autenticazione come reimpostazioni automatizzate delle password, autenticazione a più fattori, accesso API, oltre all'implementazione di protocolli più recenti e al miglioramento di quelli esistenti, esp. in termini di sicurezza.
[Disclaimer: lavoro in Microsoft in Active Directory e nel gruppo Sicurezza. Le opinioni sono mie e ho fatto il massimo sforzo per rendere questa tecnologia agonistica dal momento che si tratta di una domanda di design.]