Potrebbe non esserci una giustificazione "sicurezza", ma ci sono altre considerazioni di progettazione che vale la pena esplorare. A mio parere, il vantaggio più grande dell'utilizzo di OAuth è che si astragga il metodo di autenticazione dai vari sistemi richiesti di autenticazione / autorizzazione (questo è qualcosa che Tylerl stava descrivendo).
Ad esempio: si inizia con un servizio che si autentica contro l'utilizzo di nome utente / password JSON. Funziona tutto bene, ma decidi di introdurre un altro servizio che offre funzionalità leggermente diverse. Il nuovo servizio accetta anche nome utente e password tramite JSON.
Ad un certo punto qualcuno ti fa notare che MD5 è rotto o che non stai salendo correttamente le tue password. Nessun problema: puoi sistemarlo. Ma devi aggiustarlo in entrambi (tutti) i tuoi servizi che stanno eseguendo l'autenticazione ... Quanti di questi hai? Sai davvero dove sono tutti? Come puoi distribuire la modifica a tutti i servizi allo stesso tempo?
Eseguendo l'autenticazione con un Server di autorizzazione , come in OAuth 2.0, rimuovi parzialmente questa dipendenza. Puoi facilmente modificare i meccanismi di autenticazione all'interno di questo server e fintanto che i tuoi servizi continueranno ad accettare token OAuth, non avrai problemi.
L'altro punto importante è che OAuth è uno schema standard . Quando si parla di autenticazione, adottare schemi standard è sempre meglio che implementare i propri schemi di autenticazione. Inoltre, se volessi esporre i tuoi servizi via Internet ad un certo punto, il fatto che accetti i token di accesso OAuth renderebbe l'intero processo molto più facile.