OpenID es un protocolo para la autenticación mientras que OAuth es para autorización . La autenticación se trata de asegurarse de que la persona con la que estás hablando es, de hecho, quien dice ser. La autorización se trata de decidir qué se le debe permitir a ese tipo.

En OpenID, la autenticación está delegada: el servidor A quiere autenticar al usuario U, pero las credenciales de U (por ejemplo, el nombre y la contraseña de U) se envían a otro servidor, B, en el que A confía (al menos, confía para autenticar usuarios). De hecho, el servidor B se asegura de que U sea efectivamente U, y luego le dice a A: "ok, esa es la U genuina".

En OAuth, la autorización es delegada: la entidad A obtiene de la entidad B un "derecho de acceso" que A puede mostrar al servidor S para que se le otorgue acceso; Por lo tanto, B puede entregar claves de acceso temporales y específicas a A sin darles demasiado poder. Puede imaginar un servidor OAuth como el maestro de llaves en un gran hotel; le da a los empleados las llaves que abren las puertas de las habitaciones a las que se supone que deben ingresar, pero cada una de ellas es limitada (no da acceso a todas las habitaciones); además, las claves se autodestruyen después de unas horas.

Hasta cierto punto, se puede abusar de la autorización en alguna pseudo-autenticación, sobre la base de que si la entidad A obtiene de B una clave de acceso a través de OAuth y la muestra al servidor S, entonces el servidor S puede inferir that B autentificó A antes de otorgar la clave de acceso. Así que algunas personas usan OAuth donde deberían usar OpenID. Este esquema puede o no ser esclarecedor; pero creo que esta pseudo-autenticación es más confusa que cualquier otra cosa. OpenID Connect hace exactamente eso: abusa de OAuth en un protocolo de autenticación. En la analogía del hotel: si me encuentro con un empleado presunto y esa persona me muestra que tiene una llave que abre mi habitación, entonces supongo que este es un verdadero empleado, sobre la base de que la llave maestra no le habría dado una llave que abre mi habitación si no lo estuviera.

Términos simples

1. OpenID se trata de verificar la identidad de una persona.
2. OAuth se trata de acceder a las cosas de una persona.
3. OpenID Connect hace ambas cosas .

Los tres le permiten a una persona dar su nombre de usuario / contraseña (u otra credencial) a una autoridad confiable en lugar de a una aplicación menos confiable.

Más detalles

Para entender algo, mira su historia.

OpenID & OAuth se ha desarrollado en pistas paralelas y en 2014 se fusionó en OpenID Connect. A lo largo de su historial, OpenID y OAuth han permitido que una aplicación utilice una autoridad confiable para manejar las credenciales de los usuarios privados. Mientras que OpenID permite que la autoridad verifique la identidad de un usuario, OAuth le permite a la autoridad otorgar acceso limitado a las cosas de un usuario.

OpenID 1.0 (2006) permite que una aplicación solicite autorización a prueba de que un usuario final posee una identidad (una URL).

• Usuario final a la aplicación: Soy Steve A. Smith.
• Aplicación a la autoridad: ¿Es este Steve A. Smith?
• El usuario final y la autoridad hablan por un momento.
• Autoridad para la aplicación: Sí, ese es Steve A. Smith.

OpenID 2.0 (2007) hace lo mismo, pero agrega un segundo formato de identidad (XRI) y agrega flexibilidad a la forma en que el usuario final especifica la identidad y la autoridad.

OpenID Attribute Exchange 1.0 (2007) extiende OpenID 2.0 al permitir que una aplicación busque & almacene la información del perfil del usuario final con la autoridad, además de verificar la identidad del usuario final.

• Usuario final a la aplicación: Soy Steve A. Smith.
• Aplicación a la autoridad: ¿Es este Steve A. Smith? Ah, y si es así, también tráeme su dirección de correo electrónico y número de teléfono.
• El usuario final y la autoridad hablan por un momento.
• Autoridad para la aplicación: Sí, ese es Steve A. Smith. Su correo electrónico es [email protected] y el número de teléfono es 123-456-7890.

OAuth 1.0 (2010) permite que un usuario final otorgue a la aplicación acceso limitado a los recursos en un servidor de terceros que posee una autoridad.

• Aplicación para el usuario final: nos gustaría acceder a sus imágenes en algún otro servidor.
• El usuario final y la autoridad hablan por un momento.
• Autorización para la aplicación: aquí hay un token de acceso.
• Aplicación al servidor de terceros: aquí está el token de acceso que demuestra que puedo acceder a las imágenes para un usuario final.

OAuth 2.0 (2012) hace lo mismo que OAuth 1.0 pero con una nuevo protocolo

OpenID Connect (2014) combina las características de OpenID 2.0, OpenID Attribute Exchange 1.0 y OAuth 2.0 en un solo protocolo. Permite que una aplicación use una autoridad ...

1. para verificar la identidad del usuario final,
2. para obtener la información del perfil del usuario final, y
3. para obtener acceso limitado a las cosas del usuario final.

Muchas personas siguen visitando esto, así que aquí hay un diagrama muy simple para explicarlo

Cortesía de Wikipedia

Además de las otras respuestas: creo que mucha confusión proviene de un uso impreciso o al menos inusual de los términos Autentificación y Autorización

OpenID Connect 1.0 se comercializa como una solución de Autentificación , mientras que, por sí sola, no maneja la autenticación. La autenticación "real" en su sentido básico (proceso de validación de las credenciales del usuario para probar una identidad ) está fuera del alcance de OpenID Connect.

OpenID Connect debe comercializarse mejor como un protocolo Federation , permitiendo que una Parte que confía use el proceso de autenticación existente, la base de datos de usuarios y el manejo de sesiones de un proveedor de ID de terceros. Eso es funcionalmente similar a SAML 2.0.

Nota: estrictamente hablando, desde el punto de vista de la parte que confía, la obtención y validación de un token de ID de un proveedor de ID se puede considerar como un método de autenticación. Creo que ahí es donde "OpenID Connect es un protocolo de autenticación".

El mismo razonamiento para que OAuth 2.0 sea un protocolo de Autorización : generalmente la autorización es el proceso de definir una política de acceso que determina qué usuarios tienen acceso a qué recursos. Esa definición difícilmente se aplica a OAuth.

OAuth 2.0 está brindando a los usuarios una forma de permitir que application / client acceda a sus propios recursos en su nombre. En otras palabras, OAuth 2.0 está autorizando a las aplicaciones de clientes , no a los usuarios, para acceder a los recursos. Se supone que la Política de autorización (que otorga a usuarios acceso a los recursos) existe antes de implementar OAuth.

Habría etiquetado OAuth como un protocolo de acceso de delegación .

Pido disculpas si esa publicación aumenta aún más la confusión :)

Ya tenemos un diagrama y una gran cantidad de buenos datos, así que aquí hay un ejemplo en caso de que eso ayude.

Digamos que quiero publicar un comentario en StackOverflow. StackOverflow solo permite comentarios si un usuario tiene una reputación de 50.

StackOverflow debe autorizar esta solicitud (por ejemplo, solo permitirla si el usuario tiene > = 50 repeticiones). StackOverflow no usaría OAuth para hacer esto porque StackOverflow posee el recurso protegido. Si StackOverflow intentara publicar un comentario en Facebook en nombre del usuario, entonces usaría OAuth. En su lugar, StackOverflow utilizará la autorización local (por ejemplo, if (user.reputation < 50) throw InsufficientReputationError(); )

Para hacer esto, StackOverflow primero debe saber quién realiza la solicitud. En otras palabras, para autorizar la solicitud, primero debe autenticar la solicitud.

StackOverflow primero verifica la sesión y los encabezados HTTP para ver si el usuario puede autenticarse rápidamente (por ejemplo, esta no es su primera solicitud) pero eso falla.

Supongamos que StackOverflow ha decidido utilizar OpenID Connect. Esto significa que StackOverflow confía en un proveedor de identidad. Este es un servicio en el que StackOverflow confía que puede decirle a StackOverflow quién es el usuario actual. En este ejemplo asumiremos que es Google.

StackOverflow ahora le pregunta a Google quién es el usuario actual. Sin embargo, Google debe primero asegurarse de que StackOverflow pueda saber quién es el usuario actual. En otras palabras, Google debe autorizar StackOverflow. Como Google es el propietario del recurso protegido y StackOverflow es el que accede a él, podemos usar OAuth aquí. De hecho, OpenID Connect lo ordena.

Esto significa que StackOverflow tiene que autenticar con un servidor de autorización en el que Google confía (en realidad, esto también sería Google, pero no es así) y obtener un token de acceso. . Toma ese token de acceso a Google y solicita la identidad del usuario. Luego, Google devuelve la identidad del usuario (firmando la identidad en el camino) y StackOverflow luego autoriza la solicitud ahora que conoce la identidad del usuario.

En caso de que te lo perdieras, había varios pasos de autenticación y autorización cada uno.

• StackOverflow intentó autenticar la solicitud mediante cookies de sesión, pero falló.
• StackOverflow luego autenticó la solicitud mediante OpenID Connect
• Google autorizó la solicitud de identidad de SO mediante OAuth
• El Servidor de Autorización autenticado StackOverflow (probablemente esté usando un ID de cliente y un secreto de cliente).
• Además, como parte del flujo de trabajo de OAuth, el Servidor de Autorización puede tener autenticado la solicitud al pedirle al usuario su nombre de usuario & contraseña.
• Además, el propio usuario puede haber autorizado la solicitud de identidad de SO respondiendo a una pantalla de concesión (por ejemplo, "¿desea que StackOverflow tenga acceso a su correo electrónico?")
• StackOverflow autorizó la solicitud asegurando que el usuario tuviera > 50 reputación.

¿Qué es OpenID (sin la conexión)?

Este era un protocolo anterior que permitía que un proveedor de identidad (como Google) pasara la información del usuario a un servicio (como StackOverflow). Sin embargo, utilizó otro método (no OAuth) para que Google autorice a StackOverflow a acceder a la identidad del usuario. OpenID tenía algunos fallos de seguridad (que creo que se resolvieron) pero, en mi opinión, el verdadero asesino fue simplemente el hecho de que OAuth tenía mejor soporte y, por lo tanto, tendía a ser menos laborable que aprender el protocolo personalizado de OpenID.

A partir de hoy todo el mundo lo está abandonando. No lo uses Utilice OpenID Connect.

"Abusando de" OAuth

En el escenario que describí anteriormente, OAuth se usa exactamente como se pretende para la autorización. Sin embargo, hay otro flujo de trabajo que a menudo puede confundir a las personas. Esto ocurrió porque en muchas situaciones (¿la mayoría?) El servidor que proporciona la identidad del usuario y el servidor de autorización OAuth son el mismo servidor.

En este caso, parece un poco excesivo que una solicitud HTTP se realice primero en el servidor de autorización para obtener un token de acceso y luego nuevamente en el mismo servidor para obtener un token de identidad. Por lo tanto, se creó una extensión para la especificación OAuth para permitir que el servidor de autorización se agrupara información de identidad del usuario con el token de acceso.

Esto permite que la autenticación ocurra completamente en el navegador (por ejemplo, los servidores de StackOverflow no necesitan estar involucrados). Sin embargo, ese tipo de autenticación es menos útil y (¿creo?) Se usa con menos frecuencia.

Como ya se mencionó, Oauth es una cosa, OpenID es otra, y OpenID Connect combina las dos.

Pero, como ya se mencionó, el uso de autenticación y autorización para diferenciar Oauth y OpenID es simplemente erróneo. La autenticación, la confirmación de la veracidad de la reclamación de una entidad a una identidad almacenada, se atribuye a OpenID pero es definitivamente parte del proceso de Oauth. La autorización, el permiso para acceder a un recurso o contenedor específico, se atribuye a Oauth pero definitivamente es parte del proceso de OpenID.

En mi experiencia, la diferencia real entre Oauth y OpenID se puede ver en las actividades típicas no relacionadas con la autenticación que se realizan, y por quién, en cada esquema.

• OpenID facilita el acceso del usuario a un contenedor autorizado con recursos agrupados (por ejemplo, acceso al sitio web).
• Oauth facilita el acceso automatizado a un recurso autorizado dentro de un contenedor (por ejemplo, las operaciones CRUD en un archivo o registro a través de una API web).

OpenID Connect, entonces, le permite a un usuario acceder a una dirección web y una vez que ingresa, le da a la aplicación web subyacente una forma de recuperar recursos adicionales, fuera del sitio, en nombre del usuario.

Para resumir: OpenID Connect es una API de identidad federada que incluye un perfil y una extensión de OAuth 2.0 que permite a un cliente (es decir, una aplicación móvil o sitio web) redirigir a una persona a un proveedor de identidad central para la autenticación, y le permite a esa persona Autorizar la divulgación de información a ese cliente.

Deberías leer mi blog OAuth vs. SAML vs. OpenID Connect : enlace

La API de OpenID Connect incluye varios puntos finales, no todos relacionados con OAuth:

Puntos finales de OAuth

• Autorización : sitio web del canal frontal que representa la página de inicio de sesión y la página de autorización (consentimiento). (RFC 6749)
• Token : punto final del canal posterior, que normalmente requiere autenticación, donde un cliente puede solicitar tokens de acceso, id_tokens y tokens de actualización. (RFC 6749)
• Configuración : metadatos del proveedor publicados en .well-known/openid-configuration , incluida la ubicación de los puntos finales, los algoritmos criptográficos compatibles y otra información que necesita el cliente para interactuar con el OP. (RFC 8414)
• Registro de cliente : punto final para que una aplicación cree o actualice un cliente OAuth (RFC 7591)

Puntos finales no OAuth

• Userinfo : acceso a API protegida por token en la que el cliente puede solicitar reclamaciones sobre un tema. Este es el servidor de recursos en términos de OAuth.
• JWKS : las claves públicas actuales del OP utilizado para la firma y el cifrado
• Administración de sesión : utilizada por las tres especificaciones de cierre de sesión de OpenID (ninguna funciona tan bien)
• Webfinger : se utiliza para iniciar el descubrimiento de OP y trabajar hacia atrás desde una dirección de correo electrónico (u otro identificador), es decir, cómo se determina el punto final de configuración de un dominio. (RFC 7033, pero no es parte del OAuth WG)