¿Cuándo usa OpenID frente a OpenID Connect?

OpenID y OpenID Connect son para autenticación , no para autorización . Las dos actividades son distintas. OpenID Connect es de hecho OAuth (un protocolo de autorización) que se convierte (abusa) en un protocolo de autenticación. Más explicaciones en esta respuesta .

Hasta cierto punto, puede combinar la autenticación y la autorización, pero eso es una fuente de confusión. En su caso, aparentemente desea autenticar a los usuarios con "Google, Twitter, ...": desea que Google (o Twitter) le diga quién es el usuario , pero no lo que el usuario debería permitir hacer ; quiere que estos proveedores externos se autentiquen, no autoricen.

Otra forma de verlo es la siguiente: un usuario se conecta a su servidor S . El servidor S ofrece algunos "servicios", es decir, hará "cosas" cuando se le solicite; Sin embargo, no aceptará hacer las mismas cosas para todos. Supongamos que lo encontró adecuado para dar control de lo que S puede hacer o no para cada usuario a otro sistema que llamaremos R . R puede o no ser la misma computadora que S , pero pensemos de forma genérica y asumamos que R es diferente de S . Desde el punto de vista de S , la información necesaria está dentro del alcance de la autorización: S desea saber si la llamada se otorgará o no. Así que habrá un protocolo de autorización entre S y R . Posiblemente, S y R no hablarán directamente entre sí, sino solo a través de mensajes ("tickets") que son transportados por el cliente; Eso es un detalle técnico.

Sin embargo, para decidir si una solicitud dada a S se debe permitir o no, el servidor de autorización R debe saber quién está enviando el Solicitud, porque la respuesta depende de la identidad del usuario. Por lo tanto, R deberá autenticar al usuario; o, más genéricamente, para hablar con un servidor de autenticación T . T es responsable de asegurarse de que el usuario sea quien dice ser. Luego se produce un protocolo de autenticación entre R y T .

En su ejemplo, R es su servidor de autorización, mientras que T es Google / Twitter. Usaría OpenID entre R y T , y OAuth entre S y R .

OpenID Connect es cuando S también quiere realizar alguna autenticación; S luego usa R (quien "habla OAuth") e infiere que si R permite la solicitud, entonces R debe haber hecho algún tipo de autenticación del usuario; por lo que S decide que el usuario es realmente quien dice ser, ya que (implícitamente) está convencido de que R .

No creo que ninguna de las otras respuestas anteriores responda a la pregunta, que es la diferencia entre OpenID Connect y OpenID 2.0 . OpenID 2.0 no es OAuth 2.0 .

OpenID 2.0 y OpenID Connect son estándares muy diferentes con parámetros completamente diferentes y formatos de cuerpo de respuesta. Ambos se construyen sobre OAuth 2.0 al colocar valores adicionales en las solicitudes y respuestas OAuth 2.0 válidas para proporcionar la información de identidad necesaria para la autenticación (mientras que OAuth 2.0 solo brinda autorización, no autenticación). OpenID Connect mejoró la asignación de nombres y la estructura de los campos y parámetros OpenID 2.0 para que sea más fácil de usar. Puedo leer fácilmente la especificación OpenID Connect y entender para qué se usan todos los valores y en qué establecerlos, pero tratar de leer la especificación OpenID 2.0 es un poco más difícil y complicado.

En este punto, la elección es fácil, OpenID 2.0 está en desuso. Deberías usar OpenID Connect .

OAuth solo proporciona y debería proporcionar autorización utilizando un token de acceso. OpenID connect se basa en OAuth 2 para proporcionar información de autenticación de usuario. OpenID connect es de hecho el hijo de OpenID. Ver OpenID-Connect-Lecture -para-MIT, diapositiva 33

  

OpenID Connect 1.0 es una capa de identidad simple sobre el protocolo OAuth 2.0 [RFC6749]. Permite a los Clientes verificar la identidad del Usuario final basándose en la autenticación realizada por un Servidor de Autorización, así como obtener información básica de perfil sobre el Usuario Final de manera interoperable y similar a REST.    OpenID Connect Core 1.0 - borrador 17

Las cosas son, OpenID connect le proporciona una forma "estándar" de obtener la identidad del usuario. Si utiliza OAuth y la API, debe adaptar su solicitud para cada recurso, que puede que no siempre proporcione la misma información o que cambie con el tiempo. Y conceptualmente, utiliza OAuth para poder usar una API, no para autenticar a un usuario.

  

Como fondo, las especificaciones del Marco de Autorización OAuth 2.0 [RFC6749] y el Uso del token de portador OAuth 2.0 [RFC6750] proporcionan un marco general para que las aplicaciones de terceros obtengan y utilicen acceso limitado a los recursos HTTP. Definen los mecanismos para obtener y usar los tokens de acceso para acceder a los recursos, pero no definen los métodos estándar para proporcionar información de identidad. En particular, sin el perfil de OAuth 2.0, es incapaz de proporcionar información sobre la autenticación de un usuario final. OpenID Connect Core 1.0 - borrador 17

Tenga en cuenta que, OpenID connect proporciona un id_token con información sobre el usuario. Pero si desea todo el conjunto de información, aún necesita que access_token solicite al proveedor de OpenID que obtenga la información del usuario (que me confunde la primera vez que la veo). Ver 5.3.1. userinfo request en el borrador