Affronterò questa domanda dal punto di vista dell'usabilità e dell'estensibilità. Ad esempio, se sto progettando di utilizzare un protocollo per lo scambio di dati, ad esempio messaggi di testo tra utenti, sulla rete tra due applicazioni, la mia prima scelta sarebbe HTTP.
Perché dovrei scegliere HTTP invece di qualcosa di più semplice, ad esempio TCP non elaborato con un intestazione fatta a mano in alto? Perché l'applicazione cresce e so che tra due mesi estenderò questa semplice intestazione manuale per aggiungere la codifica del testo. Tra quattro mesi estenderò di nuovo l'intestazione per consentire il trasferimento chunked. E tra 3 anni finirò con un orribile per mantenere e documentare intestazione fatta a mano che è probabilmente buggy come l'inferno (comprese le implicazioni sulla sicurezza).
Se scelgo di usare HTTP, inizialmente sembrerà gonfio. Ma dopo 3 anni scoprirò che l'80% delle estensioni che ho aggiunto sono conformi ad alcune parti del protocollo HTTP. Quindi ho bisogno di documentare meno cose e ho bisogno di mantenere meno codice da solo.
Ora torna a OpenID 2.0 e OpenID Connect.
OpenID Connect è sovrapposto a OAuth 2.0, OpenID 2.0 no. Per molto tempo OpenID era un sistema concorrente per OAuth, tuttavia, entrambi hanno una filosofia di utilizzo leggermente diversa:
Quindi sì, stai cercando una soluzione in cui gli utenti di un posto possano accedere ad un altro posto utilizzando le stesse credenziali. Stai cercando OpenID non OAuth.
Tuttavia, è molto probabile che a un certo punto in futuro vorrà estendere questa interazione tra i due siti Web e condividere non solo le credenziali ma anche i dati tra i due . Se implementate OpenID 2.0 ora, dovrete implementare OAuth a quel punto e disporre di un software complicato in cui ci sono due diversi tipi di credenziali che girano attorno. E questo è abbastanza incline agli errori.
Se utilizzi OpenID Connect, quando gli utenti vorranno condividere i dati, avrai già costruito lo scaffold. Tutto quello che devi fare è aggiungere un'ulteriore elaborazione della chiave di valet e la tua applicazione è pulita.
Naturalmente, è solo probabile che ad un certo punto in futuro l'interazione tra i siti web dovrà aumentare. E valutare questa somiglianza va oltre le informazioni che possono essere scritte in una discussione sul confronto dei vantaggi e degli svantaggi dei due protocolli. Tuttavia, preferirei sicuramente avere un asso nella manica per quando arriva una situazione simile, piuttosto che rischiare di finire con un'estensione brutta e soggetta a errori.