¿En qué se diferencia OAuth 2 de OAuth 1?

En términos muy simples, ¿alguien puede explicar la diferencia entre OAuth 2 y OAuth 1?

¿OAuth 1 está obsoleto ahora? ¿Debería implementar OAuth 2? No veo muchas implementaciones de OAuth 2; la mayoría sigue usando OAuth 1, lo que me hace dudar de que OAuth 2 esté listo para usar. ¿Lo es?

Eran Hammer-Lahav ha hecho un excelente trabajo al explicar la mayoría de las diferencias en su artículo Presentando OAuth 2.0 . Para resumir, aquí están las diferencias clave:

Más OAuth Flows para permitir un mejor soporte para aplicaciones no basadas en navegador. Esta es una de las principales críticas en contra de OAuth por parte de las aplicaciones del cliente que no estaban basadas en el navegador. Por ejemplo, en OAuth 1.0, las aplicaciones de escritorio o las aplicaciones de teléfonos móviles tenían que indicar al usuario que abriera su navegador al servicio deseado, se autenticara con el servicio y copiara el token del servicio a la aplicación. La principal crítica aquí es contra la experiencia del usuario. Con OAuth 2.0, ahora hay nuevas formas para que una aplicación obtenga autorización para un usuario.

OAuth 2.0 ya no requiere que las aplicaciones cliente tengan criptografía. Esto recuerda a la antigua API de autenticación de Twitter, que no requería la aplicación a tokens de hash HMAC y cadenas de solicitud. Con OAuth 2.0, la aplicación puede realizar una solicitud utilizando solo el token emitido a través de HTTPS.

Las firmas OAuth 2.0 son mucho menos complicadas. No más análisis especiales, clasificación o encoding.

Los tokens de acceso de OAuth 2.0 son “de corta duración”. Normalmente, los tokens de acceso de OAuth 1.0 pueden almacenarse durante un año o más (Twitter nunca los deja caducar). OAuth 2.0 tiene la noción de tokens de actualización. Si bien no estoy del todo seguro de cuáles son estos, supongo que sus tokens de acceso pueden ser de corta vida (es decir, basados ​​en sesiones) mientras que los tokens de actualización pueden ser “de por vida”. Utilizaría un token de actualización para adquirir un nuevo token de acceso en lugar de hacer que el usuario vuelva a autorizar su aplicación.

Finalmente, OAuth 2.0 está destinado a tener una separación clara de roles entre el servidor responsable de manejar las solicitudes de OAuth y el servidor que maneja la autorización del usuario. Más información sobre eso se detalla en el artículo mencionado anteriormente.

Veo excelentes respuestas aquí, pero lo que extraño son algunos diagtwigs y, como tuve que trabajar con Spring Framework, me encontré con su explicación .

Encuentro que los siguientes diagtwigs son muy útiles. Ilustran la diferencia en la comunicación entre las partes con OAuth2 y OAuth1.


OAuth 2

enter image description here


OAuth 1

enter image description here

Las explicaciones anteriores son OMI excesivamente detalladas y complicadas. En pocas palabras, OAuth 2 delega seguridad en el protocolo HTTPS. OAuth 1 no lo requería y, en consecuencia, tenía métodos alternativos para hacer frente a diversos ataques. Estos métodos requieren que la aplicación participe en ciertos protocolos de seguridad que son complicados y pueden ser difíciles de implementar. Por lo tanto, es más sencillo confiar únicamente en HTTPS para la seguridad, de modo que los desarrolladores de aplicaciones no tengan que preocuparse por ello.

En cuanto a sus otras preguntas, la respuesta depende. Algunos servicios no desean requerir el uso de HTTPS, se desarrollaron antes de OAuth 2, o tienen algún otro requisito que puede impedirles usar OAuth 2. Además, ha habido mucho debate sobre el protocolo OAuth 2 en sí mismo. Como puede ver, Facebook, Google y algunos otros tienen versiones ligeramente diferentes de los protocolos implementados. Entonces, algunas personas se quedan con OAuth 1 porque es más uniforme en las diferentes plataformas. Recientemente, el protocolo OAuth 2 se ha finalizado, pero todavía tenemos que ver cómo se adoptará.

Tenga en cuenta que hay argumentos serios de seguridad contra el uso de Oauth 2:

un artículo sombrío

y uno más técnico

Tenga en cuenta que provienen del autor principal de Oauth 2.

Puntos clave:

  • Oauth 2 no ofrece seguridad sobre SSL mientras que Oauth 1 es independiente del transporte.

  • en cierto sentido, SSL no es seguro, ya que el servidor no verifica la conexión y las bibliotecas de clientes comunes hacen que sea fácil ignorar las fallas.

    El problema con SSL / TLS es que cuando no se puede verificar el certificado en el lado del cliente, la conexión sigue funcionando. Cada vez que ignorar un error conduce al éxito, los desarrolladores harán exactamente eso. El servidor no tiene forma de aplicar la verificación del certificado, e incluso si pudiera, un atacante seguramente no.

  • puedes deshacerte de toda tu seguridad, lo cual es mucho más difícil de hacer en OAuth 1.0:

    El segundo problema de potencial común son errores tipográficos. ¿Consideraría que es un diseño apropiado cuando se omite un carácter (la ‘s’ en ‘https’) anula toda la seguridad del token? O tal vez enviar la solicitud (a través de una conexión SSL / TLS válida y verificada) al destino equivocado (digamos ‘ http://gacebook.com ‘?). Recuerde, poder usar tokens de portador de OAuth desde la línea de comandos era claramente un uso de portadores de casos promovidos por defensores de tokens.

Las firmas OAuth 2.0 no son necesarias para las llamadas API reales una vez que se ha generado el token. Tiene solo un token de seguridad.

OAuth 1.0 requiere que el cliente envíe dos tokens de seguridad para cada llamada API, y use ambos para generar la firma. Requiere que los puntos finales de recursos protegidos tengan acceso a las credenciales del cliente para validar la solicitud.

Aquí se describe la diferencia entre OAuth 1.0 y 2.0 y cómo funcionan ambos.

La seguridad del protocolo OAuth 1.0 ( RFC 5849 ) se basa en la suposición de que una clave secreta incrustada en una aplicación cliente puede mantenerse confidencial. Sin embargo, la suposición es ingenua.

En OAuth 2.0 ( RFC 6749 ), una aplicación cliente ingenua se denomina cliente confidencial . Por otro lado, una aplicación cliente en un entorno donde es difícil mantener una clave secreta confidencial se llama cliente público . Ver 2.1. Tipos de clientes para más detalles.

En ese sentido, OAuth 1.0 es una especificación solo para clientes confidenciales.

” OAuth 2.0 y el camino al infierno ” dice que OAuth 2.0 es menos seguro, pero no existe una diferencia práctica en el nivel de seguridad entre los clientes OAuth 1.0 y los clientes confidenciales OAuth 2.0. OAuth 1.0 requiere para calcular la firma, pero no mejora la seguridad si ya está asegurado que una clave secreta en el lado del cliente puede mantenerse confidencial. La firma informática es solo un cálculo engorroso sin ninguna mejora de seguridad práctica. Es decir, en comparación con la simplicidad de que un cliente de OAuth 2.0 se conecte a un servidor a través de TLS y simplemente presente client_id y client_secret , no se puede decir que el cálculo engorroso sea mejor en términos de seguridad.

Además, RFC 5849 (OAuth 1.0) no menciona nada acerca de los redirectores abiertos, mientras que RFC 6749 (OAuth 2.0) sí lo hace. Es decir, el parámetro oauth_callback de OAuth 1.0 puede convertirse en un agujero de seguridad.

Por lo tanto, no creo que OAuth 1.0 sea más seguro que OAuth 2.0.


[14 de abril de 2016] Adición para aclarar mi punto

La seguridad de OAuth 1.0 se basa en el cálculo de firmas. Una firma se calcula utilizando una clave secreta donde una clave secreta es una clave compartida para HMAC-SHA1 ( RFC 5849, 3.4.2 ) o una clave privada para RSA-SHA1 ( RFC 5849, 3.4.3 ). Cualquiera que conozca la clave secreta puede calcular la firma. Entonces, si la clave secreta se ve comprometida, la complejidad del cálculo de la firma no tiene sentido por muy compleja que sea.

Esto significa que la seguridad de OAuth 1.0 no se basa en la complejidad y la lógica de la computación de firmas, sino simplemente en la confidencialidad de una clave secreta. En otras palabras, lo que se necesita para la seguridad de OAuth 1.0 es solo la condición de que una clave secreta pueda mantenerse confidencial. Esto puede parecer extremo, pero el cálculo de firmas no agrega mejoras de seguridad si la condición ya está satisfecha.

Del mismo modo, los clientes confidenciales de OAuth 2.0 dependen de la misma condición. Si la condición ya está satisfecha, ¿hay algún problema para crear una conexión segura usando TLS y enviar client_id y client_secret a un servidor de autorización a través de la conexión segura? ¿Hay alguna gran diferencia en el nivel de seguridad entre los clientes confidenciales OAuth 1.0 y OAuth 2.0 si ambos dependen de la misma condición?

No puedo encontrar ninguna buena razón para que OAuth 1.0 culpe a OAuth 2.0. El hecho es simplemente que (1) OAuth 1.0 es solo una especificación para clientes confidenciales y (2) OAuth 2.0 también ha simplificado el protocolo para clientes confidenciales y clientes públicos compatibles. Independientemente de si se sabe bien o no, las aplicaciones de teléfonos inteligentes se clasifican como clientes públicos ( RFC 6749, 9 ), que se benefician de OAuth 2.0.

OAuth 2 es aparentemente una pérdida de tiempo (por la boca de alguien que estuvo muy involucrado en esto):

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

Él dice (editado por brevedad y en negrita por énfasis):

… Ya no puedo asociarme con el estándar OAuth 2.0. Renuncié a mi función de autor principal y editor, retiré mi nombre de la especificación y abandoné el grupo de trabajo. Quitar mi nombre de un documento que he trabajado minuciosamente durante tres años y más de dos docenas de borradores no fue fácil. Decidí pasar de un esfuerzo que he liderado durante más de cinco años fue angustioso.

… Al final, llegué a la conclusión de que OAuth 2.0 es un mal protocolo. WS- * malo. Ya es suficientemente malo que ya no quiera estar asociado a él. … Cuando se compara con OAuth 1.0, la especificación 2.0 es más compleja, menos interoperable, menos útil, más incompleta y, lo que es más importante, menos segura.

Para que quede claro, es probable que OAuth 2.0, de la mano de un desarrollador con un profundo conocimiento de la seguridad web, sea una implementación segura. Sin embargo, en manos de la mayoría de los desarrolladores, como ha sido la experiencia de los últimos dos años, es probable que 2.0 genere implementaciones inseguras.

OAuth 2.0 promete simplificar las cosas de las siguientes maneras:

  1. Se requiere SSL para todas las comunicaciones requeridas para generar el token. Esta es una gran disminución en la complejidad porque esas firmas complejas ya no son necesarias.
  2. Las firmas no son necesarias para las llamadas API reales una vez que se ha generado el token. También se recomienda enfáticamente SSL.
  3. Una vez que se generó el token, OAuth 1.0 requirió que el cliente enviara dos tokens de seguridad en cada llamada de API, y utilizara ambos para generar la firma. OAuth 2.0 solo tiene un token de seguridad y no se requiere firma.
  4. Se especifica claramente qué partes del protocolo implementan el “propietario del recurso”, que es el servidor real que implementa la API, y qué partes pueden ser implementadas por un “servidor de autorización” separado. Eso facilitará que productos como Apigee ofrezcan compatibilidad con OAuth 2.0 a las API existentes.

Fuente: http://blog.apigee.com/detail/oauth_differences

Si necesita alguna explicación avanzada, necesita leer ambas especificaciones:

https://oauth.net/core/1.0a/

https://oauth.net/2/

Si necesita una explicación clara de las diferencias de flujo, esto podría serle útil:

Flujo de OAuth 1.0

  1. La aplicación cliente se registra con el proveedor, como Twitter.
  2. Twitter proporciona al cliente un “secreto de consumidor” exclusivo para esa aplicación.
  3. La aplicación de cliente firma todas las solicitudes de OAuth a Twitter con su exclusivo “secreto de consumidor”.
  4. Si alguna de las solicitudes de OAuth está mal formada, falta información o está firmada incorrectamente, la solicitud será rechazada.

Flujo de OAuth 2.0

  1. La aplicación cliente se registra con el proveedor, como Twitter.
  2. Twitter proporciona al cliente un “secreto de cliente” exclusivo para esa aplicación.
  3. La aplicación del cliente incluye “secreto del cliente” con cada solicitud.
  4. Si alguna de las solicitudes de OAuth está mal formada, falta información o contiene el secreto incorrecto, la solicitud será rechazada.

Fuente: https://codiscope.com/oauth-2-0-vs-oauth-1-0/

Desde el punto de vista de la seguridad, elegiría OAuth 1. Ver OAuth 2.0 y el camino al infierno

Cita de ese enlace: “Si actualmente está utilizando 1.0 con éxito, ignore 2.0. No ofrece ningún valor real sobre 1.0 (supongo que los desarrolladores de su cliente ya han descubierto 1.0 firmas por ahora).

Si es nuevo en este espacio y se considera un experto en seguridad, use 2.0 después de un examen cuidadoso de sus características. Si no es un experto, use 1.0 o copie la implementación 2.0 de un proveedor en el que confía para hacerlo bien (los documentos API de Facebook son un buen lugar para comenzar). 2.0 es mejor para una gran escala, pero si está ejecutando una operación importante, es probable que tenga algunos expertos en seguridad para resolverlo por usted “.