Pregunta ¿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?


506
2017-11-06 16:18


origen


Respuestas:


Eran Hammer-Lahav ha hecho un excelente trabajo al explicar la mayoría de las diferencias en su artículo Presentamos 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 codificación.

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. Aunque no estoy del todo seguro de cuáles son, 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.


448
2017-11-08 17:02



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

Encuentro que los siguientes diagramas 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


146
2017-12-13 12:32



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


76
2017-10-30 19:00



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 (decir '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.


27
2018-03-01 22:04



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í describe la diferencia entre OAuth 1.0 y 2.0 y cómo funcionan ambos.


21
2018-01-09 06:02



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 llama confidencial cliente. Por otro lado, una aplicación cliente en un entorno donde es difícil mantener una clave secreta confidencial se llama público cliente. Ver 2.1. Tipos de cliente para 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 de 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 OAuth 2.0 se conecta a un servidor a través de TLS y solo presenta 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 sobre redirectores abiertos mientras que RFC 6749 (OAuth 2.0) sí lo hace. Es decir, oauth_callback el parámetro 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, OAuth 2.0 confidencial los clientes confían en la misma condición. Si la condición ya está satisfecha, ¿hay algún problema al crear una conexión segura usando TLS y enviando 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 ha simplificado el protocolo para clientes confidenciales y es compatible público clientes, también. 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.


19
2018-03-03 14:34



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 ser   asociado con el estándar OAuth 2.0. Renuncié a mi papel como líder   autor y editor, retire mi nombre de la especificación, y se fue   el grupo de trabajo. Eliminar mi nombre de un documento que tengo   laboriosamente trabajado durante tres años y más de dos docenas de borradores   no fue fácil Decidí pasar de un esfuerzo que he llevado a cabo por más de   cinco años fue agonizante.

... 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 quiero ser   asociado a ello. ... Cuando se compara con OAuth 1.0, el 2.0   la especificación es más compleja, menos interoperable, menos útil, más   incompleto, y lo más importante, menos seguro.

Para ser claro, OAuth 2.0 de la mano de un desarrollador con profundas   la comprensión de la seguridad web es probable que resulte un seguro   implementación. Sin embargo, a manos de la mayoría de los desarrolladores, como ha sido   la experiencia de los últimos dos años - 2.0 es probable que produzca   implementaciones inseguras.


19
2018-06-28 11:59



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


6
2018-03-14 05:14



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. Aplicación de cliente señales todas las solicitudes de OAuth a Twitter con es único "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. Aplicación 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/


3
2018-04-10 14:40



Desde un punto de vista de seguridad, iría por 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).

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 ".


1
2017-11-28 12:52