¿Cuál es la diferencia entre OpenID y OAuth?

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

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

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

La entrada del blog ” OpenID versus OAuth desde la perspectiva del usuario ” tiene una simple comparación de los dos desde la perspectiva del usuario y ” OAuth-OpenID: Ladra el árbol equivocado si crees que son lo mismo ” tiene más información al respecto.

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 fundamental porque todo el objective de OpenID es que se puede usar cualquier proveedor (con la excepción de las listas blancas). No es necesario pre-elegir o negociar un acuerdo con los proveedores para permitir a los usuarios usar 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 de HTTP Basic (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 uno de ellos proporciona un conjunto diferente de características que son deseadas por diferentes implementaciones, pero esencialmente, son bastante intercambiables. En esencia, ambos protocolos son un método de verificación de aseveración (OpenID está limitado a la afirmación “esto es lo que soy”, mientras que OAuth proporciona un “token de acceso” que puede intercambiarse por cualquier afirmación soportada a través de una API).

2. Características

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

OpenID : la característica más importante de OpenID es su proceso de descubrimiento. OpenID no requiere una encoding rígida para cada uno de los proveedores que desea utilizar con anticipación. Con el descubrimiento, el usuario puede elegir cualquier proveedor de terceros que quiera 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 HTTP como identificadores que la mayoría de los usuarios de la web simplemente no obtienen. Otras características que OpenID tiene es su soporte para el registro ad-hoc de clientes usando un intercambio de DH, modo inmediato para la experiencia optimizada del usuario final, y una forma de verificar las afirmaciones sin hacer 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 finaliza con la autenticación, sino que proporciona un token de acceso para obtener acceso a recursos adicionales proporcionados por el mismo servicio de terceros. Sin embargo, dado que OAuth no es compatible con el descubrimiento, se requiere preseleccionar y codificar los proveedores que usted decida usar. Un usuario que visite su sitio no puede usar ningún identificador, solo aquellos que preseleccionó. 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 hace Twitter) o hacer otra llamada API para obtener el usuario actualmente “conectado”.

3. Implementaciones técnicas

Los dos protocolos comparten una architecture 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.

OpenID es (principalmente) para identificación / autenticación, por lo que stackoverflow.com sabe que soy dueño de chris.boyle.name (o donde sea) y por lo tanto, que probablemente soy la misma persona que poseía chris.boyle.name ayer y me chris.boyle.name algunos puntos de reputación .

OAuth está diseñado para autorizar la adopción de medidas en su nombre, de modo que stackoverflow.com (o donde sea) pueda pedir permiso para, por ejemplo, twittear en su nombre automáticamente, sin conocer su contraseña de Twitter.

Muchas personas aún visitan esto, así que aquí hay un diagtwig muy simple para explicarlo

OpenID_vs._pseudo-authentication_using_OAuth

Cortesía Wikipedia

OAuth

Solo se utiliza para la authorization delegada, lo que significa que autoriza a un servicio de terceros a utilizar datos personales, sin dar una contraseña. Además, las “sesiones” de OAuth generalmente duran más que las sesiones de los usuarios. 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 una persona en su nombre, sin que tengan que dar su nombre de usuario y contraseña.

OpenID

Se usa para authenticate identidad de inicio de sesión único. Se supone que todo lo que OpenID debe hacer es permitir que un proveedor de OpenID pruebe que usted dice que lo es. Sin embargo, muchos sitios usan autenticación de identidad para proporcionar autorización (sin embargo, los dos se pueden separar)

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án usando.

Use OAuth si sus usuarios solo desean iniciar sesión con Facebook o Twitter. Use OpenID si sus usuarios son parientes que manejan sus propios proveedores de OpenID porque “no quieren que nadie más tenga su identidad”.

OpenID y OAuth son cada uno de los protocolos basados ​​en HTTP para autenticación y / o autorización. Ambos están destinados a permitir a los usuarios realizar acciones sin dar credenciales de autenticación o permisos globales a clientes o terceros. Si bien son similares, y existen estándares propuestos para usarlos juntos, son protocolos separados.

OpenID está destinado a la autenticación federada. Un cliente acepta una afirmación de identidad de cualquier proveedor (aunque los clientes son libres de incluir en la lista blanca o en la lista negra a los proveedores).

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 es más adecuado para la autorización, ya que las interacciones posteriores a la autenticación están incorporadas en el protocolo, pero ambos protocolos están evolucionando. OpenID y sus extensiones se pueden usar para la autorización, y OAuth se puede usar para la autenticación, que se puede considerar como una autorización no operativa.

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

OpenID Connect es un protocolo de autenticación como OpenID 1.0 / 2.0 pero en realidad se basa en 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/

Más una extensión de la pregunta que una respuesta, pero puede agregar alguna perspectiva a las grandes respuestas técnicas anteriores. Soy un progtwigdor experimentado en varias áreas, pero soy un novato total en la progtwigción de la web. Ahora bash crear una aplicación basada en la 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 cada vez mayor de usuarios la idea de tener otro nombre de usuario y contraseña es disuasorio. Si bien no son exactamente redes sociales, 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 desea ni necesita acceder a la información sobre la cuenta del usuario desde esos sitios, solo desea ofrecer la comodidad de no requerir al usuario que establezca nuevas credenciales de cuenta si no lo desea. Desde el punto de vista de la funcionalidad, eso parecería un niño poster 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 cómo difieren, hasta que no vi la observación de Karl Anderson anterior, hasta que “OAuth puede utilizarse para la autenticación, que puede considerarse como una autorización no operativa”, Vi una 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”, no siendo miembro en ese momento, miré detenidamente al final de esta página las opciones para identificarme. La opción de usar un inicio de sesión de OpenID u obtener uno si no tuviera uno, pero nada sobre twitter o Facebook, parecía sugerir que OAuth no era adecuado para el trabajo. Pero luego abrí otra ventana y busqué el proceso de registro general para stackoverflow, y he aquí que hay una gran variedad de opciones de autenticación de terceros, como Facebook y Twitter. Al final, decidí usar mi ID de Google (que es un OpenID) precisamente por el motivo de que no quería otorgar acceso de stackoverflow a mi lista de amigos y cualquier otra cosa que Facebook quisiera 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 genial si alguien pudiera publicar información o sugerencias sobre información sobre cómo admitir este tipo de configuración de autorización múltiple de terceros y sobre 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 de stackoverflow única a la que pude acceder con autenticación básica si quería configurarla, y también acceder a esta misma cuenta a través de otros autenticadores de terceros (por ejemplo, para que me consideren registrado en stackoverflow si estuve conectado a cualquiera de google, facebook o twitter …). Dado que este sitio lo está haciendo, alguien aquí probablemente tenga una idea bastante buena sobre el 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 hilos en OAuth y OpenID. Si hay un lugar mejor para esto que no encontré, me disculpo de antemano, lo intenté.

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

OpenID es un protocolo de autenticación, mientras que OAuth es para autorización. La autenticación se trata de asegurarse de que el tipo con el que está hablando sea quien dice ser. La autorización consiste en 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 en autenticar usuarios). De hecho, el servidor B se asegura de que U sea de hecho 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; De este modo, B puede entregar claves de acceso temporales y específicas a A sin darles demasiada potencia. Puede imaginar un servidor OAuth como el maestro clave 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 llave es limitada (no da acceso a todas las habitaciones); además, las teclas se autodestruyen después de unas horas.

Hasta cierto punto, se puede abusar de la autorización en alguna pseudoautenticació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 A antes de otorgar el acceso llave. Entonces, 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 justamente eso: abusa de OAuth en un protocolo de autenticación. En la analogía del hotel: si encuentro un supuesto empleado 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 el maestro clave no le habría dado una llave que abre mi habitación si no fuera así.

(fuente)

¿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 apta para API y utilizable 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 se integran con el protocolo en sí.

(fuente)

OpenID Connect te 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 oauth2 deja a la elección. por ejemplo, ámbitos, descubrimiento de punto final y registro dynamic de clientes.

Esto hace que sea más fácil escribir código que le permita al usuario elegir entre múltiples proveedores de identidad.

(fuente)

Google OAuth 2.0

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á certificada por OpenID. La documentación que se encuentra en Usar 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 Google OAuth 2.0 Playground .

(fuente)

OpenID demuestra quién eres.

OAuth otorga acceso a las funciones provistas por la parte autorizante.

OpenID Connect (OIDC) es un protocolo de autenticación, basado en la familia de especificaciones OAuth 2.0 (es decir, O pen Auth orization). Utiliza Tokens Web JSON (JWT) simples, 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 se trata de acceso e intercambio de recursos, OIDC tiene que ver con la autenticación de usuarios. 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 OpenID donde inicia sesión y luego lo lleva al sitio web.

Por ejemplo , si elige iniciar sesión en Auth0 con su cuenta de Google, entonces utilizó OIDC . Una vez que se haya autenticado exitosamente con Google y autorice Auth0 para acceder a su información, Google le enviará nuevamente a Auth0 información sobre el usuario y la autenticación realizada. Esta información se devuelve en un token web JSON (JWT). Recibirás un token de acceso y, si se solicita, un token de identificación.

Analogía : una tarjeta de identificación de uso de la organización con fines de identificación y contiene fichas, almacena detalles sobre el empleado junto con la autorización, es decir, el acceso al campus / puerta / ODC. La tarjeta de identificación actúa como OIDC y la tarjeta de identificación con chip actúa como OAuth . más Analogía de OAuth

Fuente

Actualmente estoy trabajando en OAuth 2.0 y las especificaciones de conexión de OpenID. Así que aquí está mi entendimiento: antes eran:

  1. OpenID fue una implementación patentada de Google que permite aplicaciones de terceros, como sitios web de periódicos, puede iniciar sesión usando google y comentar un artículo, entre otros usos. Así que esencialmente, no se comparte la contraseña en el sitio web del periódico. Permítanme poner una definición aquí, este enfoque en el enfoque empresarial se llama Federación. En Federation, tiene un servidor donde se autentica y autoriza (llamado IDP, Identity Provider) y generalmente es el guardián de las credenciales del usuario. la aplicación del cliente donde tiene negocios se llama SP o Proveedor de servicios. Si volvemos al mismo sitio web del periódico, entonces el sitio web del periódico es SP aquí y Google es IDP. En la empresa, este problema se resolvió con SAML. ese tiempo XML utilizado para gobernar la industria del software. Entonces, desde los servicios web hasta la configuración, todo solía ir a XML, así que tenemos SAML, un protocolo de federación completo
  2. OAuth: OAuth vio su surgimiento como un estándar que contemplaba todo este tipo de enfoques propietarios y, por lo tanto, teníamos OAuth 1.o como estándar, pero solo abordaba la autorización. No mucha gente lo notó, pero comenzó a mejorar. Luego tuvimos OAuth 2.0 en 2012. CTOs, los arquitectos realmente comenzaron a prestar atención a medida que el mundo avanza hacia la computación en la nube y con los dispositivos informáticos que se mueven hacia los dispositivos móviles y otros dispositivos similares. OAuth consideraba que era la solución de un gran problema donde los clientes de software podían dar el servicio IDP a una empresa y tenían muchos servicios de diferentes proveedores como salesforce, SAP, etc. Por lo tanto, la integración aquí parece una situación de federación, un gran problema, usar SAML es costoso así que exploremos OAuth 2.o. Ohh, olvidé un punto importante que durante este tiempo, Google detectó que OAuth en realidad no aborda la Autenticación, cómo IDP dará datos de usuario a SP (que en realidad se aborda maravillosamente en SAML) y con otros cabos sueltos como:

    a. OAuth 2.o no dice claramente cómo se registrará el cliente b. no menciona nada acerca de la interacción entre SP (Servidor de recursos) y la aplicación cliente (como el Servidor de análisis que proporciona datos es el Servidor de recursos y la aplicación que muestra esos datos es Cliente)

Ya hay respuestas maravillosas dadas aquí técnicamente, pensé en dar una breve perspectiva de evolución

OpenId usa OAuth para tratar con la autenticación.

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

Lo mismo con OpenId / OAuth. OpenId depende de OAuth para administrar la Autenticación, pero define un Token específico (Id_token), firma digital y flujos particulares.

Quisiera abordar un aspecto particular de esta pregunta, como se refleja en este comentario:

OAuth: antes de otorgar acceso a alguna característica, la autenticación debe hacerse, ¿verdad? entonces OAuth = ¿Qué hace OpenId + otorga acceso a algunas funciones? – Hassan Makarov 21 de junio a la 1:57

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

Cuando el flujo de OAuth lo redirecciona a un servicio objective (es decir, al 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 propiedad de un usuario determinado” implica que “usted y el propietario del recurso (s) objective 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 quizás certificaciones de clientes SSL, o por otros medios), lo que el cliente obtenga a cambio no necesariamente debe tomarse como prueba de identidad. Un ejemplo sería un flujo en el que se le delegó el acceso a los recursos de otro usuario (y por proxy, el cliente OAuth). La autorización no implica autenticación.

Para manejar la autenticación, es probable que desee examinar OpenID Connect, que es esencialmente otra capa en la parte superior de 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 https://oauth.net/articles/authentication/ ):

OpenID Connect es un estándar abierto publicado a principios de 2014 que define una forma interoperable de utilizar OAuth 2.0 para realizar la autenticación de usuario. En esencia, es una receta ampliamente publicada para chocolate dulce que ha sido probada y probada por un amplio número y variedad de expertos. En lugar de crear un protocolo diferente para cada proveedor de identidad potencial, una aplicación puede comunicar un protocolo a tantos proveedores como desee. Debido a que es un estándar abierto, OpenID Connect puede ser implementado por cualquier persona sin restricciones o preocupaciones 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 en la parte superior de) una infraestructura de OAuth. OpenID Connect también utiliza el conjunto de especificaciones JSON Object Signing And Encryption (JOSE Object Signing And Encryption) 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 inconvenientes mencionados anteriormente mediante la adición de varios componentes clave a la base de OAuth: […]

El documento continúa describiendo (entre otras cosas) identificaciones de token 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 preguntar al servicio ascendente), y este último proporciona una medios de, por ejemplo, preguntar el nombre / apellido, correo electrónico y otros datos similares del usuario, todo de manera estandarizada (a diferencia de las extensiones ad-hoc de OAuth que las personas usaban antes de las cosas normalizadas de OpenID Connect).

OAuth construye la autenticación además de la autorización: el usuario delega el acceso a su identidad a la aplicación, que luego se convierte en consumidor de la API de identidad, descubriendo así quién autorizó al cliente en primer lugar http://oauth.net/ artículos / autenticación /