español - ¿Cuál es la diferencia entre OpenID y OAuth?

openid connect (17)

¿Realmente estoy tratando de entender la diferencia entre OpenID y OAuth? Tal vez son dos cosas totalmente separadas?

Actualmente estoy trabajando en OAuth 2.0 y OpenID connect spec. Así que aquí está mi entendimiento: antes eran:

OpenID fue una implementación patentada de Google que permite aplicaciones de terceros, como sitios web de periódicos en los que puede iniciar sesión con google y comentar un artículo y otros casos de uso. Esencialmente, no hay contraseña para compartir con el sitio web del periódico. Permítanme poner una definición aquí, este enfoque en el enfoque empresarial se llama Federación. En la Federación, tiene un servidor en el que se autentica y autoriza (llamado IDP, Proveedor de Identidad) y, en general, el custodio de las credenciales del Usuario. La aplicación cliente en la que tiene negocios se llama SP o Proveedor de servicios. Si volvemos al mismo ejemplo del sitio web del periódico, el sitio web del periódico es SP aquí y Google es IDP. En la empresa, este problema se resolvió anteriormente utilizando SAML. Ese tiempo XML utilizado para gobernar la industria del software. Entonces, desde los servicios web hasta la configuración, todo lo que se usa para ir a XML es para tener SAML, un protocolo de federación completo.
OAuth: OAuth vio su surgimiento como un estándar que contempla este tipo de enfoques patentados y, por lo tanto, teníamos OAuth 1.o como estándar, pero solo abordamos la autorización. No mucha gente se dio cuenta pero comenzó a mejorar. Luego tuvimos OAuth 2.0 en 2012. CTO, los arquitectos realmente comenzaron a prestar atención a medida que el mundo avanzaba hacia la computación en nube y con los dispositivos informáticos que se movían hacia dispositivos móviles y otros dispositivos similares. OAuth fue considerado como la solución de un gran problema en el que los clientes de software pueden brindar el Servicio IDP a una empresa y tienen muchos servicios de diferentes proveedores como Salesforce, SAP, etc. Por lo tanto, la integración aquí parece un escenario de federación, un gran problema, el uso de SAML es costoso. así que vamos a explorar OAuth 2.o. Ohh, se perdió un punto importante que durante este tiempo, Google percibió que OAuth en realidad no aborda la Autenticación, cómo IDP entregará los datos de usuario a SP (que en realidad se aborda de manera maravillosa en SAML) y con otros cabos sueltos como:
a. OAuth 2.o no dice claramente cómo ocurrirá el registro del cliente b. no menciona nada sobre la interacción entre el SP (servidor de recursos) y la aplicación cliente (como Analytics Server que proporciona datos es el servidor de recursos y la aplicación que muestra que los datos son cliente)

Técnicamente, ya hay respuestas maravillosas que se dan aquí. Pensé en dar una breve perspectiva de la evolución.

Ambos protocolos fueron creados por diferentes razones. OAuth fue creado para autorizar a terceros a acceder a los recursos. OpenID fue creado para realizar la descentralización de validación de identidad. Este website establece lo siguiente:

OAuth es un protocolo diseñado para verificar la identidad de un usuario final y otorgar permisos a un tercero. Esta verificación da como resultado un token. El tercero puede usar este token para acceder a los recursos en nombre del usuario. Los tokens tienen un alcance. El alcance se utiliza para verificar si un recurso es accesible para un usuario o no

OpenID es un protocolo utilizado para la autenticación descentralizada. La autenticación es acerca de la identidad; Establecer al usuario es, de hecho, la persona que dice ser. Descentralizar eso significa que este servicio no tiene conocimiento de la existencia de ningún recurso o aplicación que deba protegerse. Esa es la diferencia clave entre OAuth y OpenID.

Creo que tiene sentido revisar esta pregunta como también se señaló en los comentarios, la introducción de OpenID Connect puede haber traído más confusión.

OpenID Connect es un protocolo de autenticación como OpenID 1.0 / 2.0, pero en realidad está construido sobre OAuth 2.0, por lo que obtendrá funciones de autorización junto con funciones de autenticación. La diferencia entre los dos está bastante bien explicada en detalle en este artículo (relativamente reciente, pero importante): http://oauth.net/articles/authentication/

Hay tres formas de comparar OAuth y OpenID:

1. propósitos

OpenID se creó para la autenticación federada, es decir, permitir que un tercero autentique a sus usuarios por usted, mediante el uso de cuentas que ya tienen . El término federado es crítico aquí porque todo el punto de OpenID es que se puede usar cualquier proveedor (con la excepción de las listas blancas). No es necesario realizar una elección previa o negociar un acuerdo con los proveedores para permitir que los usuarios utilicen cualquier otra cuenta que tengan.

OAuth se creó para eliminar la necesidad de que los usuarios compartan sus contraseñas con aplicaciones de terceros . En realidad, comenzó como una forma de resolver un problema de OpenID: si admite OpenID en su sitio, no puede usar las credenciales HTTP básicas (nombre de usuario y contraseña) para proporcionar una API porque los usuarios no tienen una contraseña en su sitio.

El problema es que esta separación de OpenID para la autenticación y OAuth para la autorización es que ambos protocolos pueden lograr muchas de las mismas cosas. Cada una de ellas proporciona un conjunto diferente de características que son deseadas por diferentes implementaciones pero esencialmente, son bastante intercambiables. En su núcleo, ambos protocolos son un método de verificación de aserción (OpenID se limita a la aserción ''este es quien soy'', mientras que OAuth proporciona un ''token de acceso'' que se puede intercambiar por cualquier aserción admitida a través de una API).

2. Características

Ambos protocolos proporcionan una manera para que un sitio redirija a un usuario a otro lugar y vuelva con una afirmación verificable. OpenID proporciona una aserción de identidad, mientras que OAuth es más genérico en forma de un token de acceso que luego se puede usar para "hacer preguntas al proveedor de OAuth" . Sin embargo, cada uno soporta diferentes características:

OpenID : la característica más importante de OpenID es su proceso de descubrimiento. OpenID no requiere una codificación rígida para cada uno de los proveedores que desea utilizar antes de tiempo. Mediante el descubrimiento, el usuario puede elegir cualquier proveedor externo que desee autenticar. Esta característica de descubrimiento también ha causado la mayoría de los problemas de OpenID porque la forma en que se implementa es mediante el uso de URI de HTTP como identificadores que la mayoría de los usuarios de la web simplemente no obtienen. Otras características de OpenID es su soporte para el registro de clientes ad-hoc mediante un intercambio DH, el modo inmediato para la experiencia optimizada del usuario final y una forma de verificar las afirmaciones sin tener que realizar otro viaje de ida y vuelta al proveedor.

OAuth : la característica más importante de OAuth es el token de acceso que proporciona un método duradero para realizar solicitudes adicionales. A diferencia de OpenID, OAuth no termina con la autenticación, pero proporciona un token de acceso para obtener acceso a recursos adicionales proporcionados por el mismo servicio de terceros. Sin embargo, dado que OAuth no admite el descubrimiento, requiere la preselección y la codificación de los proveedores que decida utilizar. Un usuario que visita su sitio no puede usar ningún identificador, solo aquellos previamente seleccionados por usted. Además, OAuth no tiene un concepto de identidad, por lo que usarlo para iniciar sesión significa agregar un parámetro personalizado (como lo hizo Twitter) o hacer otra llamada a la API para obtener el usuario "registrado" actualmente.

3. Implementaciones técnicas

Los dos protocolos comparten una arquitectura común al usar la redirección para obtener la autorización del usuario. En OAuth, el usuario autoriza el acceso a sus recursos protegidos y en OpenID, a su identidad. Pero eso es todo lo que comparten.

Cada protocolo tiene una forma diferente de calcular una firma utilizada para verificar la autenticidad de la solicitud o respuesta, y cada uno tiene diferentes requisitos de registro.

Más una extensión de la pregunta que una respuesta, pero puede agregar algo de perspectiva a las grandes respuestas técnicas anteriores. Soy un programador experimentado en varias áreas, pero un noob total a la programación para la web. Ahora tratando de construir una aplicación basada en web usando Zend Framework.

Definitivamente implementará una interfaz de autenticación de nombre de usuario / contraseña básica específica de la aplicación, pero reconozca que para un número creciente de usuarios, la idea de otro nombre de usuario y contraseña es un elemento disuasivo. Si bien no es exactamente una red social, sé que un gran porcentaje de los usuarios potenciales de la aplicación ya tienen cuentas de facebook o twitter. La aplicación realmente no quiere o necesita acceder a la información sobre la cuenta del usuario desde esos sitios, solo quiere ofrecer la comodidad de no requerir que el usuario configure las nuevas credenciales de la cuenta si no lo desean. Desde el punto de vista de la funcionalidad, eso parece un elemento secundario para OpenID. Pero parece que ni Facebook ni Twitter son proveedores de OpenID como tales, aunque sí admiten la autenticación OAuth para acceder a los datos de sus usuarios.

En todos los artículos que he leído sobre los dos y en qué se diferencian, no será hasta que vi la observación anterior de Karl Anderson, que "OAuth se puede usar para la autenticación, que se puede considerar como una autorización sin operación" que Vi cualquier confirmación explícita de que OAuth era lo suficientemente bueno para lo que quería hacer.

De hecho, cuando fui a publicar esta "respuesta", al no ser miembro en ese momento, busqué detenidamente en la parte inferior de esta página las opciones para identificarme. La opción para usar un inicio de sesión de OpenID u obtener uno si no tenía uno, pero nada sobre Twitter o Facebook, parecía sugerir que OAuth no era adecuada para el trabajo. Pero luego abrí otra ventana y busqué el proceso general de registro para , y he aquí que hay una gran cantidad de opciones de autenticación de terceros, como Facebook y Twitter. Al final, decidí usar mi ID de Google (que es un OpenID) exactamente por la razón por la que no quería otorgarle acceso a a mi lista de amigos y cualquier otra cosa que a Facebook le guste compartir sobre sus usuarios, pero al menos es una Prueba de que OAuth es adecuado para el uso que tenía en mente.

Sería realmente genial si alguien pudiera publicar información o apuntar a información sobre la compatibilidad con este tipo de configuración de autorización múltiple de la tercera parte, y cómo tratar con los usuarios que revocan la autorización o pierden el acceso a su sitio de terceros. También tengo la impresión de que mi nombre de usuario aquí identifica una cuenta única de a la que podría acceder con la autenticación básica si quisiera configurarlo, y también a esta misma cuenta a través de autenticadores de terceros (por ejemplo, para que me consideren registrado). en si inicié sesión en cualquiera de google, facebook o twitter ...). Ya que este sitio lo está haciendo, alguien aquí probablemente tenga una buena idea del tema. :-)

Lo siento, esto fue tan largo y más una pregunta que una respuesta, pero la observación de Karl hizo que pareciera el lugar más apropiado para publicar en medio del volumen de subprocesos en OAuth y OpenID. Si hay un lugar mejor para esto que no encontré, me disculpo de antemano, lo intenté.

Me gustaría abordar un aspecto particular de esta pregunta, como se refleja en este comentario:

OAuth: antes de otorgar acceso a alguna característica, se debe realizar la autenticación, ¿no? así que OAuth = ¿qué OpenId otorga + otorga acceso a algunas características? - Hassan Makarov 21 de junio a las 1:57

Si y no. La respuesta es sutil, así que tengan paciencia conmigo.

Cuando el flujo de OAuth lo redirecciona a un servicio de destino (es decir, el proveedor de OAuth), es probable que deba autenticarse con ese servicio antes de que se devuelva un token a la aplicación / servicio cliente. El token resultante permite que la aplicación cliente realice solicitudes en nombre de un usuario determinado.

Tenga en cuenta la generalidad de la última frase: específicamente, escribí "en nombre de un usuario determinado", no "en nombre de usted ". Es un error común suponer que "tener la capacidad de interactuar con un recurso que es propiedad de un usuario determinado" implica que "usted y el propietario de los recursos objetivo son uno en el mismo".

No cometas este error.

Si bien es cierto que se autentica con el proveedor de OAuth (por ejemplo, por nombre de usuario y contraseña, o tal vez certificados de cliente SSL, o algún otro medio), lo que el cliente obtiene a cambio no debe tomarse necesariamente como prueba de identidad. Un ejemplo sería un flujo en el que el acceso a los recursos de otro usuario fue delegado a usted (y por proxy, el cliente OAuth). La autorización no implica autenticación.

Para manejar la autenticación, probablemente querrá mirar en OpenID Connect, que es esencialmente otra capa sobre la base establecida por OAuth 2.0. Aquí hay una cita que captura (en mi opinión) los puntos más destacados con respecto a OpenID Connect (de here ):

OpenID Connect es un estándar abierto publicado a principios de 2014 que define una forma interoperable de usar OAuth 2.0 para realizar la autenticación de usuario. En esencia, es una receta ampliamente publicada para el dulce de chocolate que ha sido probada y probada por un gran número y variedad de expertos. En lugar de crear un protocolo diferente para cada proveedor de identidad potencial, una aplicación puede hablar un protocolo a tantos proveedores como quieran trabajar. Dado que es un estándar abierto, OpenID Connect puede ser implementado por cualquier persona sin restricciones o problemas de propiedad intelectual.
OpenID Connect se basa directamente en OAuth 2.0 y, en la mayoría de los casos, se implementa junto con (o sobre) una infraestructura de OAuth. OpenID Connect también utiliza el conjunto de especificaciones de firma y cifrado de objetos JSON (JOSE) para llevar información firmada y encriptada en diferentes lugares. De hecho, una implementación de OAuth 2.0 con capacidades JOSE ya es un largo camino para definir un sistema OpenID Connect totalmente compatible, y el delta entre los dos es relativamente pequeño. Pero ese delta hace una gran diferencia, y OpenID Connect se las arregla para evitar muchos de los escollos mencionados anteriormente agregando varios componentes clave a la base de OAuth: [...]

Luego, el documento describe (entre otras cosas) las ID de tokens y un punto final UserInfo. El primero proporciona un conjunto de reclamos (quién es usted, cuándo se emitió el token, etc., y posiblemente una firma para verificar la autenticidad del token a través de una clave pública publicada sin tener que solicitar el servicio ascendente), y el último proporciona una medios, por ejemplo, para solicitar el nombre / apellido del usuario, el correo electrónico y bits de información similares, todo de forma estandarizada (a diferencia de las extensiones ad-hoc de OAuth que las personas usaban antes de las cosas estandarizadas de OpenID Connect).

Muchas personas todavía visitan esto, así que aquí hay un diagrama muy simple para explicarlo.

Wikipedia cortesía

OAuth construye la autenticación sobre la autorización: el usuario delega el acceso a su identidad a la aplicación, que luego se convierte en un consumidor de la API de identidad, por lo que descubre quién autorizó al cliente en primer lugar http://oauth.net/articles/authentication/

OpenID y OAuth son protocolos basados en HTTP para la autenticación y / o autorización. Ambos están destinados a permitir que los usuarios realicen acciones sin otorgar credenciales de autenticación o permisos generales a clientes o terceros. Si bien son similares, y hay estándares propuestos para usarlos a la vez, son protocolos separados.

OpenID está destinado a la autenticación federada. Un cliente acepta una aserción de identidad de cualquier proveedor (aunque los clientes son gratuitos para los proveedores de listas blancas o negras).

OAuth está destinado a la autorización delegada. Un cliente se registra con un proveedor, que proporciona tokens de autorización que aceptará para realizar acciones en nombre del usuario.

Actualmente, OAuth se adapta mejor a la autorización, ya que se incorporan más interacciones después de la autenticación en el protocolo, pero ambos protocolos están evolucionando. OpenID y sus extensiones se podrían usar para la autorización, y OAuth se puede usar para la autenticación, que se puede considerar como una autorización sin operación.

OpenId utiliza OAuth para tratar con la autenticación.

Por analogía, es como .NET se basa en la API de Windows. Puede llamar directamente a la API de Windows, pero es muy amplio, complejo y los argumentos de método son tan vastos que fácilmente podría cometer errores / errores / problemas de seguridad.

Lo mismo con OpenId / OAuth. OpenId confía en OAuth para administrar la autenticación pero definiendo un token específico (Id_token), firma digital y flujos particulares.

Use OAuth si sus usuarios solo quieren iniciar sesión con Facebook o Twitter. Use OpenID si sus usuarios son fanáticos del cuello que manejan sus propios proveedores de OpenID porque "no quieren que nadie más posea su identidad".

OpenID se trata de la autenticación (es decir, de demostrar quién es usted), OAuth se trata de la autorización (es decir, para otorgar acceso a la funcionalidad / datos / etc. sin tener que lidiar con la autenticación original).

OAuth podría usarse en sitios de socios externos para permitir el acceso a datos protegidos sin que tengan que volver a autenticar a un usuario.

La publicación del blog " OpenID versus OAuth desde la perspectiva del usuario " tiene una comparación simple de las dos desde la perspectiva del usuario y " OAuth-OpenID: estás ladrando el árbol equivocado si crees que es lo mismo " tiene más información acerca de eso

La explicación de la diferencia entre OpenID, OAuth, OpenID Connect:

OpenID es un protocolo para 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 quien dice ser. La autorización se trata de decidir qué se le debe permitir a ese tipo.
En OpenID, la autenticación es 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; él le da a los empleados las llaves que abren las puertas de las habitaciones a las que se supone que deben entrar, pero cada llave 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 que B autenticó A antes de otorgar el acceso llave. Así que algunas personas usan OAuth donde deberían usar OpenID. Este esquema puede o no ser esclarecedor; pero creo que esta seudo autenticación es más confusa que cualquier otra cosa. OpenID Connect hace precisamente 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, supongo que es un verdadero empleado, sobre la base de que el maestro de llaves no le habría dado una llave. Lo que abre mi habitación si no estaba.

(source)

¿En qué se diferencia OpenID Connect de OpenID 2.0?
OpenID Connect realiza muchas de las mismas tareas que OpenID 2.0, pero lo hace de una manera que es amigable con las API y que pueden ser utilizadas por aplicaciones nativas y móviles. OpenID Connect define mecanismos opcionales para la firma robusta y el cifrado. Mientras que la integración de OAuth 1.0a y OpenID 2.0 requería una extensión, en OpenID Connect, las capacidades de OAuth 2.0 están integradas con el protocolo en sí.

(source)

OpenID connect le dará un token de acceso más un token de identificación. El token de identificación es un JWT y contiene información sobre el usuario autenticado. Está firmado por el proveedor de identidad y se puede leer y verificar sin acceder al proveedor de identidad.
Además, OpenID Connect estandariza un par de cosas que auth2 deja a su elección. por ejemplo, ámbitos, descubrimiento de puntos finales y registro dinámico de clientes.
Esto facilita la escritura de código que permite al usuario elegir entre varios proveedores de identidad.

(source)

OAuth 2.0 de Google

Las API de OAuth 2.0 de Google se pueden usar tanto para la autenticación como para la autorización. Este documento describe nuestra implementación de OAuth 2.0 para la autenticación, que cumple con la especificación de OpenID Connect, y está certificado por OpenID. La documentación que se encuentra en Uso de OAuth 2.0 para acceder a las API de Google también se aplica a este servicio. Si desea explorar este protocolo de forma interactiva, le recomendamos el área de juegos de Google OAuth 2.0 .

(source)

OAuth

Solo se usa para authorization delegada, lo que significa que está autorizando el acceso de un servicio de terceros para el uso de datos personales, sin proporcionar una contraseña. También las "sesiones" de OAuth generalmente viven más tiempo que las sesiones de usuario. Lo que significa que OAuth está diseñado para permitir la autorización

es decir, Flickr usa OAuth para permitir que los servicios de terceros publiquen y editen una imagen de personas en su nombre, sin que tengan que dar su nombre de usuario y contraseña de parpadeo.

OpenID

Se utiliza para authenticate identidad de inicio de sesión único. Todo lo que OpenID debe hacer es permitir que un proveedor de OpenID demuestre que usted dice que lo es. Sin embargo, muchos sitios utilizan la autenticación de identidad para proporcionar autorización (sin embargo, los dos pueden separarse)

es decir, Uno muestra su pasaporte en el aeropuerto para autenticar (o probar) el nombre de la persona que figura en el boleto que está usando.

OpenID Connect (OIDC) es un protocolo de autenticación, basado en la familia de especificaciones OAuth 2.0 (es decir, la autenticación O pen). Utiliza simples JSON Web Tokens (JWT), que puede obtener utilizando flujos que cumplan con las especificaciones de OAuth 2.0 . OAuth está directamente relacionado con OpenID Connect (OIDC) ya que OIDC es una capa de autenticación construida sobre OAuth 2.0

Si bien OAuth 2.0 es sobre el acceso y el uso compartido de recursos, es decir, la Autorización, OIDC tiene que ver con la autenticación del usuario. Su propósito es darle un inicio de sesión para múltiples sitios. Cada vez que necesita iniciar sesión en un sitio web utilizando OIDC , se le redirige a su sitio de OpenID en el que inicia sesión, y luego se lo devuelve al sitio web.

OpenID Connect (OIDC) es una capa de autenticación sobre OAuth 2.0, un marco de autorización. El estándar está controlado por la Fundación OpenID .:

Por ejemplo , si eligió iniciar sesión en Auth0 con su cuenta de Google, utilizó OIDC . Una vez que se autentique con éxito en Google y autorice a Auth0 a acceder a su información, Google enviará de vuelta a Auth0 la información sobre el usuario y la autenticación realizada. Esta información se devuelve en un JSON Web Token (JWT). Recibirá un token de acceso y, si se solicita, un token de ID. Tipos de Token : Fuente: OpenID Connect

Analogía
Una tarjeta de identificación de uso de la Organización con fines de identificación y que contiene chips, almacena los detalles sobre el Empleado junto con la Autorización, es decir, el acceso al Campus / Gate / ODC. La tarjeta de identificación actúa como un OIDC y el chip actúa como un OAuth . más ejemplos

OpenID prueba quién eres.

OAuth otorga acceso a las funciones proporcionadas por la parte que autoriza.

OpenID es (principalmente) para identificación / autenticación, por lo que .com sabe que tengo chris.boyle.name (o donde sea) y, por lo tanto, soy probablemente la misma persona que poseyó chris.boyle.name ayer y ganó algunos puntos de reputación .

OAuth está diseñado para que la autorización realice acciones en su nombre, de modo que .com (o donde sea) pueda pedir permiso, digamos, hacer Tweet en su nombre automáticamente, sin saber su contraseña de Twitter.