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


604

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

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



Si desea ver una explicación concisa y un flujo detallado (con diagramas) de OAuth, puede visitar oauthbible.com
Chris Ismael

Puede encontrar su respuesta aquí OAuth 2.0 - Descripción general
John Joe

Respuestas:


529

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

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 las aplicaciones 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, autenticarse con el servicio y copiar el token del servicio nuevamente 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 se remonta a la antigua API de autenticación de Twitter, que no requería la aplicación de tokens 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, ordenación o codificación especiales.

Los tokens de acceso de OAuth 2.0 son de "corta duración". Por lo general, los tokens de acceso OAuth 1.0 se pueden almacenar 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 completamente seguro de cuáles son, supongo que sus tokens de acceso pueden ser de corta duración (es decir, basados ​​en la sesión) mientras que sus 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 que el usuario vuelva a autorizar su aplicación.

Finalmente, OAuth 2.0 está destinado a tener una separación limpia 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 al respecto se detalla en el artículo mencionado.


2
¿Alguien podría aclarar cómo las URL de devolución de llamada son diferentes entre oauth 1 y 2?
Brian Armstrong

2
OAuth 2.0 solo eliminará OAuth si se aprueba como RFC. Actualmente es un borrador de Internet, pero está previsto que se convierta en un estándar de Internet (en la medida en que estas cosas puedan planificarse). Sin embargo, esto llevará años, ya que gran parte del marco aún no se ha especificado. Probablemente veremos una familia completa de borradores de Internet que se publicarán en los próximos años, cada uno con respecto a diferentes aspectos del marco de autorización de OAuth 2.0. Para ver por qué esto es cierto, visite tools.ietf.org/html/draft-ietf-oauth-v2 , y busque "más allá del alcance de esta especificación";)
Håvard Geithus

48
El autor del artículo escribió un seguimiento el año pasado llamado "OAuth 2.0 y el camino al infierno", que se puede leer aquí: web.archive.org/web/20120731155632/http://hueniverse.com/2012/… Una diferencia significativa en los dos es la seguridad, como lo presagia la falta de criptografía en 2.0.
kdazzle

44
La seguridad de OAuth 1.0 se basa en el supuesto de que una clave secreta incrustada en una aplicación cliente puede mantenerse confidencial, pero el supuesto es ingenuo. En OAuth 2.0, una aplicación de cliente tan ingenua se llama cliente confidencial . 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 2.0 y el camino al infierno" se pierde este punto.
Takahiko Kawasaki

66
@kdazzle, ese enlace ahora se ha movido aquí: hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529
e_i_pi

193

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

Los siguientes diagramas me parecen muy útiles. Ilustran la diferencia en la comunicación entre las partes con OAuth2 y OAuth1.


OAuth 2

ingrese la descripción de la imagen aquí


OAuth 1

ingrese la descripción de la imagen aquí


3
¿Dónde se usa "client_secret" en este flujo?
ashwintastic

3
Si te refieres al secreto que el usuario ingresa cuando se lo redirige al proveedor (por ejemplo, Facebook, Twitter, Google, etc.), este sería el paso 2 para OAuth 2y el paso 4 para OAuth 1.
nyxz

¿Por qué ambos diagramas tienen un paso de proveedor de servicios llamado "Autorización de concesión de usuarios"? Esto parece al revés o incorrecto. ¿No es el "usuario" el que busca la autorización?
Forbin

@Forbin Porque este paso ocurre del lado del proveedor de servicios. Está en su página donde ve las subvenciones que el servicio requiere de usted y tiene que aceptar compartir esta información con el servicio al que está intentando autenticarse. StackOverflow realmente tiene la opción de iniciar sesión con la cuenta de Google. Funciona de la misma manera. SO le pedirá a Google que vea su correo electrónico y usted debe aceptarlo.
nyxz

92

Las explicaciones anteriores son todas demasiado detalladas y complicadas de la OMI. 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 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 en el 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 quieren requerir el uso de HTTPS, se desarrollaron antes de OAuth 2 o tienen algún otro requisito que les impida usar OAuth 2. Además, se ha debatido mucho sobre el protocolo OAuth 2 en sí. 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 tomará su adopción.


11
Entonces, ¿básicamente OAuth2 funciona con HTTPS y, por lo tanto, es más simple que OAuth1, que debe ser un poco más complejo ya que puede funcionar sin HTTPS?
Micro

@MicroR ¡Esta es una definición práctica que obtuviste allí! ;)
EralpB

36

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

un artículo sombrío

y uno más técnico

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

Puntos clave:

  • Oauth 2 no ofrece seguridad además de 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 comunes de clientes facilitan ignorar las fallas.

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

  • puede eliminar toda su seguridad, lo cual 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 cuando omite un carácter (la '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, poder usar tokens portadores de OAuth desde la línea de comando fue claramente un token de portadores de casos de uso promovido por los defensores.


44
el argumento "error tipográfico" no es muy válido: es una práctica común redirigir de http a https
Oleg Mikheev

2
@OlegMikheev Sí, pero solo se necesita una solicitud http (no-s) para permitir que un MITM detecte sus encabezados y su token ahora está siendo utilizado por otra persona.
Patrick James McDougle

3
si por encabezados te refieres a cookies, se supone que son seguras . Aparte de eso, no veo cómo el error tipográfico del usuario (en la URL del navegador) puede exponer tokens, ni siquiera se supone que estén en encabezados
Oleg Mikheev

2
Como un punto adicional contra el argumento "error tipográfico", un proveedor de servicios puede rechazar cualquier solicitud de OAuth 2.0 que no sea a través de https y revocar el token de acceso en esa solicitud.
skeller88

32

La seguridad del protocolo OAuth 1.0 ( RFC 5849 ) se basa en el supuesto 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 de cliente tan ingenua se llama cliente confidencial . Por otro lado, una aplicación de cliente en un entorno donde es difícil mantener confidencial una clave secreta 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 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 se garantiza 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. Es decir, en comparación con la sencillez que un OAuth 2.0 conecta el cliente a un servidor a través de TLS y se presenta solo client_idy client_secret, que no se puede decir que el cálculo engorroso es 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í. Es decir, el oauth_callbackpará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] Además para aclarar mi punto

La seguridad de OAuth 1.0 se basa en el cálculo de la firma. 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 se ve comprometida, la complejidad del cálculo de la firma no tiene sentido por 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 la firma, 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 sonar extremo, pero el cálculo de la firma no agrega mejoras de seguridad si la condición ya se cumple.

Del mismo modo, los clientes confidenciales de OAuth 2.0 confían en la misma condición. Si la condición se cumple ya, ¿hay algún problema en la creación de una conexión segura mediante TLS y el envío client_idy client_secreta 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 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 también ha simplificado el protocolo para clientes confidenciales y clientes públicos compatibles . 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.


77
El envío de secretos en lugar de firmas, ya sea a través de HTTP, HTTPS, etc., siempre conllevará un riesgo de seguridad implícito debido a MITM a nivel de protocolo. Ahora hay 2 formas de encontrar secretos en lugar de solo 1: rootear el dispositivo o falsificar certificados raíz (ha sucedido antes, por lo que no es descabellado). Cuando su modelo de seguridad es "eh, deje que el transporte lo maneje", es cierto que no será MENOS seguro que el protocolo. Pero los modelos de seguridad monolíticos == un punto de entrada para muchos servicios. Es "lo suficientemente bueno" para los ingenieros pragmáticos, pero nunca será "tan seguro" como un modelo descentralizado alternativo.
Mark G.

23

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 a la API, y use ambos para generar la firma. Requiere que los puntos finales de los 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.


22

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

https://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 rol como 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. 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- * malo. Es lo suficientemente malo que ya no quiero estar asociado con él. ... En comparación con OAuth 1.0, la especificación 2.0 es más compleja, menos interoperable, menos útil, más incompleta y, lo más importante, menos segura.

Para ser claros, OAuth 2.0 de la mano de un desarrollador con un profundo conocimiento de la seguridad web probablemente resulte 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.


77
Tenga en cuenta que se desaconsejan las respuestas de solo enlace, las referencias tienden a quedarse obsoletas con el tiempo. Considere agregar una sinopsis independiente aquí, manteniendo el enlace como referencia.
kleopatra

66
La seguridad de OAuth 1.0 se basa en la suposición de que una clave secreta incrustada en una aplicación cliente puede mantenerse confidencial, pero la suposición es ingenua en el caso de las aplicaciones de teléfonos inteligentes. En OAuth 2.0, una aplicación de cliente tan ingenua se llama cliente confidencial . 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 2.0 y el camino al infierno" se pierde este punto.
Takahiko Kawasaki

15

Si necesita alguna explicación avanzada, debe 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:

OAuth 1.0 Flow

  1. La aplicación del cliente se registra con el proveedor, como Twitter.
  2. Twitter proporciona al cliente un "secreto del consumidor" exclusivo de esa aplicación.
  3. La aplicación cliente firma todas las solicitudes de OAuth en Twitter con su exclusivo "secreto del consumidor".
  4. Si alguna de las solicitudes de OAuth tiene un formato incorrecto, falta información o se firma incorrectamente, la solicitud será rechazada.

OAuth 2.0 Flow

  1. La aplicación del cliente se registra con el proveedor, como Twitter.
  2. Twitter proporciona al cliente un "secreto de cliente" exclusivo de esa aplicación.
  3. La aplicación del cliente incluye "secreto del cliente" con cada solicitud comúnmente como encabezado http.
  4. Si alguna de las solicitudes de OAuth tiene un formato incorrecto, falta información o contiene un secreto incorrecto, la solicitud será rechazada.

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


2
¿Podrías ver los signos en negrita? Tal vez funcional podría tener el mismo concepto pero, técnicamente hablando, usar un encabezado simple (oauth2) es muy diferente firmar la solicitud completa. Presta atención y mejora tu comprensión de lectura antes de marcar las respuestas como no útiles
JRichardsz

1
por favor lea su propia respuesta e intente darle sentido. "Firma todas las solicitudes con secreto" y "envía secreto con todas las solicitudes". Nadie en su sano juicio va a entender la diferencia aquí a menos que ya los haya usado. Sé la diferencia pero el OP no. Esta respuesta solo confundirá a OP aún más, por lo tanto, los votos negativos. Tales respuestas vagas merecen un voto negativo. Lea otras respuestas aquí que son mucho más específicas e informativas.
saran3h

12 desarrolladores lo consiguieron. oauth1 y oauth2 tienen muchas diferencias. Las respuestas anteriores las cubren y, como dije , puedes leer este oauth.net/core/1.0a o este oauth.net/2 para hacer tu propia respuesta. Mi objetivo es mostrar una de las diferencias técnicas más notorias cuando un desarrollador necesita desarrollar un cliente de descanso.
JRichardsz

7

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. No se requieren firmas para las llamadas API reales una vez que se ha generado el token; aquí también se recomienda SSL.
  3. Una vez que se generó el token, OAuth 1.0 requirió que el cliente enviara dos tokens de seguridad en cada llamada a la API, y usar ambos para generar la firma. OAuth 2.0 tiene solo un token de seguridad y no se requiere firma.
  4. 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 facilitará que productos como Apigee ofrezcan compatibilidad con OAuth 2.0 a las API existentes.

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


1

Desde el punto de vista de la seguridad, iría por OAuth 1. Vea 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 sus clientes ya han descubierto las firmas 1.0 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íe para hacerlo bien (los documentos API de Facebook son un buen lugar para comenzar). 2.0 es mejor para gran escala, pero si está ejecutando una operación importante, probablemente tenga algunos expertos en seguridad en el sitio para resolverlo todo por usted ".

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.