Tomaré esta pregunta desde el punto de vista de usabilidad y extensibilidad. Por ejemplo, si planeo usar un protocolo para intercambiar datos, digamos mensajes de texto entre usuarios, a través de la red entre dos aplicaciones, mi primera opción sería HTTP.
¿Por qué elegiría HTTP en lugar de algo más simple, por ejemplo, TCP sin formato con un encabezado hecho a mano en la parte superior? Porque la aplicación crece, y sé que dentro de dos meses extenderé este simple encabezado hecho a mano para agregar codificación de texto. Dentro de cuatro meses extenderé el encabezado nuevamente para permitir la transferencia fragmentada. Y dentro de 3 años terminaré con un horrible mantenimiento y documento de encabezado hecho a mano que probablemente tenga muchos errores (incluidas las implicaciones de seguridad).
Si elijo usar HTTP, al principio se verá hinchado. Pero después de 3 años, descubriré que el 80% de las extensiones que he agregado son conformes con alguna parte del protocolo HTTP. Así que necesito documentar menos cosas, y necesito mantener menos código yo mismo.
Y ahora, de vuelta a OpenID 2.0 vs. OpenID Connect.
OpenID Connect se coloca sobre OAuth 2.0, OpenID 2.0 no. Durante mucho tiempo, OpenID fue un sistema concurrente para OAuth, sin embargo, ambos tienen una filosofía de uso ligeramente diferente:
Entonces, sí, está buscando una solución en la que los usuarios de un lugar puedan acceder a otro lugar utilizando las mismas credenciales. Usted está detrás de OpenID no OAuth.
Sin embargo, es muy probable que en algún momento en el futuro desee ampliar esta interacción entre los dos sitios web y compartir no solo las credenciales sino también los datos entre los dos . Si implementas OpenID 2.0 ahora, necesitarás implementar OAuth en ese punto y tendrás un software de mal humor en el que hay dos tipos diferentes de credenciales flotando alrededor. Y eso es bastante propenso a errores.
Si opta por OpenID Connect, entonces, cuando los usuarios quieran compartir datos, ya habrá construido los andamios. Todo lo que deberá hacer es agregar un procesamiento adicional de la clave de valet y su aplicación estará limpia.
Por supuesto, es solo probable que en algún momento en el futuro la interacción entre los sitios web deberá aumentar. Y evaluar esta semejanza va más allá de la información que se puede escribir en una discusión sobre la comparación de las ventajas y desventajas de los dos protocolos. Sin embargo, prefiero tener un as en el hoyo para cuando llegue una situación así, en lugar de arriesgarme a terminar con una extensión fea y propensa a errores.