L'obiettivo è avere maggiore flessibilità essendo in grado di combinare più provider.
In passato, il passaggio da un fornitore all'altro poteva essere molto complicato e richiedere una riscrittura di ogni applicazione che si basava su un vecchio provider. Inoltre, se si desidera poter interrogare più provider, è necessario implementare quella parte anche nell'applicazione.
Con l'autorizzazione basata sulle attestazioni, la tua domanda può semplicemente dire "Mi fido di quel fornitore". Spetta quindi al fornitore decidere cosa fare con le richieste di applicazione: può elaborarle direttamente o delegarle ad altri fornitori. Pertanto, passare da un subfornitore all'altro o combinarne di più comporta la modifica della configurazione del provider, senza influire su nessuna delle applicazioni, senza modifiche del codice.
Esempio pratico:
L'azienda A disponeva di un database storico con informazioni sui dipendenti, ma alcuni mesi fa ha iniziato la migrazione verso un popolare servizio OpenID. Nel frattempo, è stato acquistato dalla società B che ha anche un database storico e attualmente migra verso un servizio OAuth. L'azienda A ha circa cinquanta applicazioni interne e l'azienda B ne ha venti. L'obiettivo è garantire che tutte queste applicazioni funzionino per i dipendenti di entrambe le società.
Senza l'autorizzazione basata sulle attestazioni, questa operazione probabilmente implicherebbe la modifica di tutte le settanta applicazioni.
Con l'autorizzazione basata sulle attestazioni, tutto ciò che devi fare è riconfigurare l'utente del provider di attestazioni per la società A e quello utilizzato dalla società B. La modifica sarà trasparente per le applicazioni.
Per ulteriori informazioni sull'argomento, consultare Guida all'identità e al controllo di accesso basati sulle attestazioni . È ben lungi dall'essere conciso, ma è ben scritto e spiega molto bene i sistemi basati sulle attestazioni concettualmente , invece di dire semplicemente come implementarli tecnicamente in un prodotto software.