diferencias entre oauth y oauth2
¿En qué se diferencia OAuth 2 de OAuth 1? (10)
Desde un punto de vista de seguridad, optaría por OAuth 1. Ver OAuth 2.0 y el camino al infierno
cita de ese enlace: "Si actualmente usa 1.0 con éxito, ignore 2.0. No ofrece un valor real por encima de 1.0 (supongo que los desarrolladores de sus clientes ya han descubierto las firmas 1.0 a estas alturas).
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 de confianza para hacerlo bien (los documentos de la API de Facebook son un buen lugar para comenzar). 2.0 es mejor para la gran escala, pero si está ejecutando una operación importante, es probable que tenga algunos expertos en seguridad en el sitio para resolverlo todo por usted ".
En términos muy simples, ¿alguien puede explicar la diferencia entre OAuth 2 y OAuth 1?
¿Está OAuth 1 obsoleto ahora? ¿Debería estar implementando 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 Introducing OAuth 2.0 . Para resumir, aquí están las principales diferencias:
Más flujos de OAuth para permitir un mejor soporte para aplicaciones no basadas en navegador. Esta es una crítica principal contra OAuth de aplicaciones cliente que no estaban basadas en navegador. Por ejemplo, en OAuth 1.0, las aplicaciones de escritorio o de teléfono móvil tenían que dirigir al usuario para que abriera su navegador al servicio deseado, se autentificara con el servicio y volviera a copiar el token del servicio en 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 se remonta a la antigua API de autenticación de Twitter, que no requería la aplicación para los tokens hash HMAC y las 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, clasificación o codificación especiales.
Los tokens de acceso OAuth 2.0 son "de corta duración". Por lo general, los tokens de acceso OAuth 1.0 se pueden almacenar por un año o más (Twitter nunca deja que caduquen). OAuth 2.0 tiene la noción de tokens de actualización. Si bien no estoy completamente seguro de qué son, creo que sus tokens de acceso pueden ser de corta duración (es decir, basados en sesiones), mientras que los tokens de actualización pueden ser "de por vida". Usaría un token de actualización para adquirir un nuevo token de acceso en lugar de 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.
La seguridad del protocolo OAuth 1.0 ( RFC 5849 ) se basa en el supuesto de que una clave secreta incorporada en una aplicación cliente puede mantenerse confidencial. Sin embargo, el supuesto es ingenuo.
En OAuth 2.0 ( RFC 6749 ), una aplicación de cliente tan ingenua se denomina cliente confidencial . Por otro lado, una aplicación cliente en un entorno donde es difícil mantener confidencial una clave secreta se denomina 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.
" hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529 " 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 de OAuth 2.0. OAuth 1.0 requiere calcular la firma, pero no mejora la seguridad si ya está seguro de 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 práctica de seguridad. Quiero 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 simplemente 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 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 puntoLa 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. Por lo tanto, si la clave secreta está comprometida, la complejidad del cálculo de firmas carece de significado, por muy compleja que sea.
Esto significa que la seguridad de OAuth 1.0 no se basa en la complejidad y la lógica del cálculo 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 ninguna mejora de seguridad si la condición ya se cumple.
Asimismo, los clientes confidenciales de OAuth 2.0 confían en la misma condición. Si la condición ya está satisfecha, ¿existe algún problema para crear una conexión segura utilizando TLS y enviar client_id y client_secret a un servidor de autorización a través de la conexión segura? ¿Hay alguna diferencia grande en el nivel de seguridad entre los clientes confidenciales de OAuth 1.0 y OAuth 2.0 si ambos confían en 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 solo para clientes confidenciales y (2) OAuth 2.0 ha simplificado el protocolo para clientes confidenciales y clientes públicos compatibles, también. Independientemente de si se conoce 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.
Las explicaciones anteriores son todas OMI demasiado detalladas y complicadas. En pocas palabras, OAuth 2 delega la seguridad al protocolo HTTPS. OAuth 1 no requería esto y, en consecuencia, tenía métodos alternativos para lidiar con varios ataques. Estos métodos requerían que la aplicación se involucrara en ciertos protocolos de seguridad que son complicados y pueden ser difíciles de implementar. Por lo tanto, es más simple simplemente confiar en el HTTPS para la seguridad, de modo que los desarrolladores de aplicaciones no tengan que preocuparse por eso.
En cuanto a tus otras preguntas, la respuesta depende. Algunos servicios no quieren requerir el uso de HTTPS, se desarrollaron antes de OAuth 2, o tienen algún otro requisito que pueda impedirles usar OAuth 2. Además, ha habido mucho debate sobre el protocolo de OAuth 2 en sí. Como puede ver, Facebook, Google y algunos otros tienen versiones ligeramente diferentes de los protocolos implementados. Así que 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 aún tenemos que ver cómo tomará su adopción.
Las firmas de OAuth 2.0 no son necesarias para las llamadas API reales una vez que se ha generado el token. Tiene un solo token de seguridad.
OAuth 1.0 requiere que el cliente envíe dos tokens de seguridad para cada llamada a la API y use ambos para generar la firma. Requiere que los puntos de recursos protegidos tengan acceso a las credenciales del cliente para validar la solicitud.
Here describe la diferencia entre OAuth 1.0 y 2.0 y cómo funcionan ambos.
OAuth 2 es aparentemente una pérdida de tiempo (de la boca de alguien que estuvo involucrado):
hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529
Él dice (editado por brevedad y en negrita para enfatizar):
... Ya no puedo estar asociado con el estándar OAuth 2.0. Renuncié a mi papel como autor principal y editor, retiré mi nombre de la especificación y dejé el grupo de trabajo. Eliminar mi nombre de un documento que he trabajado laboriosamente durante tres años y más de dos docenas de borradores no fue fácil. Decidir pasar de un esfuerzo que he liderado durante 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- * mal. Ya es bastante malo que ya no quiera estar asociado con é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, OAuth 2.0 de la mano de un desarrollador con un profundo conocimiento de la seguridad web resultará en una implementación segura. Sin embargo, a manos de la mayoría de los desarrolladores, como ha sido la experiencia de los últimos dos años, es probable que 2.0 produzca implementaciones inseguras.
Si necesitas una explicación avanzada necesitas leer ambas especificaciones:
Si necesita una explicación clara de las diferencias de flujo, esto podría ser de ayuda:
OAuth 1.0 Flujo
- La aplicación del cliente se registra con el proveedor, como Twitter.
- Twitter proporciona al cliente un "secreto del consumidor" exclusivo de esa aplicación.
- La aplicación del cliente firma todas las solicitudes de OAuth a Twitter con su exclusivo "secreto del consumidor".
- Si alguna de las solicitudes de OAuth tiene un formato incorrecto, faltan datos o se firma incorrectamente, la solicitud será rechazada.
OAuth 2.0 Flow
- La aplicación del cliente se registra con el proveedor, como Twitter.
- Twitter proporciona al cliente un "secreto de cliente" exclusivo de esa aplicación.
- La aplicación del cliente incluye "secreto de cliente" con cada solicitud.
- Si alguna de las solicitudes de OAuth tiene un formato incorrecto, faltan datos o contiene un secreto incorrecto, la solicitud será rechazada.
Tenga en cuenta que hay argumentos de seguridad serios contra el uso de Oauth 2:
hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529
Tenga en cuenta que estos vienen 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 porque el servidor no verifica la conexión y las bibliotecas de clientes comunes facilitan 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 aún funciona. En cualquier momento, ignorar un error lleva al éxito, los desarrolladores van a hacer eso. El servidor no tiene forma de hacer cumplir la verificación de certificados, e incluso si pudiera, un atacante seguramente no lo hará.
Usted puede sacar toda su seguridad, que es mucho más difícil de hacer en OAuth 1.0:
El segundo problema potencial común son los errores tipográficos. ¿Consideraría que es un diseño adecuado al omitir un carácter (las ''s'' en ''https'') anula toda la seguridad del token? O tal vez enviando la solicitud (a través de una conexión SSL / TLS válida y verificada) al destino incorrecto (diga '' http://gacebook.com ''). Recuerde, ser capaz de usar tokens de portador OAuth desde la línea de comando fue claramente un uso de tokens de portador de caso promovido por los defensores.
Veo grandes respuestas aquí arriba, pero lo que echo de menos fueron algunos diagramas y, como tuve que trabajar con Spring Framework, encontré su explicación .
Encuentro los siguientes diagramas muy útiles. Ilustran la diferencia en la comunicación entre las partes con OAuth2 y OAuth1.
OAuth 2
OAuth 1
OAuth 2.0 promete simplificar las cosas de las siguientes maneras:
- Se requiere SSL para todas las comunicaciones requeridas para generar el token. Esta es una gran disminución de la complejidad porque esas firmas complejas ya no son necesarias.
- No se requieren firmas para las llamadas API reales una vez que se ha generado el token. También se recomienda encarecidamente SSL aquí.
- Una vez que se generó el token, OAuth 1.0 requería que el cliente enviara dos tokens de seguridad en cada llamada a la API y usara ambos para generar la firma. OAuth 2.0 tiene un solo token de seguridad y no se requiere firma.
- Se especifica claramente qué partes del protocolo son implementadas por 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 hará que sea más fácil para los productos como Apigee ofrecer soporte de OAuth 2.0 a las API existentes.