OAuth es un estándar abierto para la delegación de acceso , comúnmente utilizado como una forma para que los usuarios de Internet otorguen a sitios web o aplicaciones acceso a su información en otros sitios web pero sin darles las contraseñas. [1] [2] Este mecanismo es utilizado por empresas como Amazon , [3] Google , Facebook , Microsoft y Twitter para permitir que los usuarios compartan información sobre sus cuentas con aplicaciones o sitios web de terceros.
Generalmente, OAuth proporciona a los clientes un "acceso delegado seguro" a los recursos del servidor en nombre del propietario del recurso. Especifica un proceso para que los propietarios de recursos autoricen el acceso de terceros a los recursos de su servidor sin proporcionar credenciales. Diseñado específicamente para trabajar con el Protocolo de transferencia de hipertexto (HTTP), OAuth esencialmente permite que un servidor de autorización emita tokens de acceso a clientes de terceros, con la aprobación del propietario del recurso. Luego, el tercero usa el token de acceso para acceder a los recursos protegidos alojados por el servidor de recursos. [4]
OAuth es un servicio complementario y distinto de OpenID . OAuth no está relacionado con OATH , que es una arquitectura de referencia para la autenticación, no un estándar para la autorización. Sin embargo, OAuth está directamente relacionado con OpenID Connect (OIDC), ya que OIDC es una capa de autenticación construida sobre OAuth 2.0. OAuth tampoco está relacionado con XACML , que es un estándar de política de autorización. OAuth se puede usar junto con XACML, donde OAuth se usa para el consentimiento de propiedad y la delegación de acceso, mientras que XACML se usa para definir las políticas de autorización (por ejemplo, los administradores pueden ver documentos en su región).
Historia
OAuth comenzó en noviembre de 2006 cuando Blaine Cook estaba desarrollando la implementación de Twitter OpenID . Mientras tanto, Ma.gnolia necesitaba una solución para permitir que sus miembros con OpenID autorizaran a los widgets del tablero para acceder a su servicio. Cook, Chris Messina y Larry Halff de Magnolia se reunieron con David Recordon para discutir el uso de OpenID con las API de Twitter y Magnolia para delegar la autenticación. Llegaron a la conclusión de que no había estándares abiertos para la delegación de acceso a API. [5]
El grupo de discusión de OAuth se creó en abril de 2007, para que el pequeño grupo de implementadores redactara el borrador de la propuesta para un protocolo abierto. DeWitt Clinton de Google se enteró del proyecto OAuth y expresó su interés en apoyar el esfuerzo. En julio de 2007, el equipo redactó una especificación inicial. Eran Hammer se unió y coordinó las muchas contribuciones de OAuth creando una especificación más formal. El 4 de diciembre de 2007, se publicó el borrador final de OAuth Core 1.0. [6]
En la 73ª reunión del Grupo de Trabajo de Ingeniería de Internet (IETF) en Minneapolis en noviembre de 2008, se llevó a cabo una BoF de OAuth para discutir la incorporación del protocolo al IETF para un mayor trabajo de estandarización. El evento contó con una gran asistencia y hubo un amplio apoyo para constituir formalmente un grupo de trabajo de OAuth dentro del IETF.
El protocolo OAuth 1.0 se publicó como RFC 5849, una solicitud de comentarios informativa , en abril de 2010.
Desde el 31 de agosto de 2010, todas las aplicaciones de Twitter de terceros deben utilizar OAuth. [7]
El marco OAuth 2.0 se publicó como RFC 6749, y el Bearer Token Usage como RFC 6750, ambos estándares realizan un seguimiento de las solicitudes de comentarios , en octubre de 2012.
OAuth 2.0
OAuth 2.0 no es compatible con versiones anteriores de OAuth 1.0. OAuth 2.0 proporciona flujos de autorización específicos para aplicaciones web, aplicaciones de escritorio, teléfonos móviles y dispositivos inteligentes . La especificación y las RFC asociadas son desarrolladas por el IETF OAuth WG; [8] el marco principal se publicó en octubre de 2012.
Facebook 's Graph API sólo admite OAuth 2.0. [9] Google admite OAuth 2.0 como el mecanismo de autorización recomendado para todas sus API . [10] Microsoft también admite OAuth 2.0 para varias API y su servicio Azure Active Directory, [11] que se utiliza para proteger muchas API de Microsoft y de terceros.
El marco de trabajo OAuth 2.0 [12] y el uso del token de portador [13] se publicaron en octubre de 2012.
El marco de autorización de OAuth 2.1 está en la etapa de borrador. [14]
Seguridad
OAuth 1.0
El 23 de abril de 2009, se anunció una falla de seguridad de fijación de sesión en el protocolo 1.0. Afecta el flujo de autorización de OAuth (también conocido como "OAuth de 3 vías") en OAuth Core 1.0 Sección 6. [15] La versión 1.0a del protocolo OAuth Core se emitió para abordar este problema. [dieciséis]
OAuth 2.0
En enero de 2013, el Grupo de trabajo de ingeniería de Internet publicó un modelo de amenazas para OAuth 2.0. [17] Entre las amenazas descritas se encuentra una llamada "Redirector abierto"; a principios de 2014, Wang Jing describió una variante de esto con el nombre de "Redirección encubierta". [18] [19] [20] [21]
OAuth 2.0 se ha analizado mediante un análisis de protocolo web formal. Este análisis reveló que en configuraciones con múltiples servidores de autorización, uno de los cuales se comporta de manera maliciosa, los clientes pueden confundirse acerca del servidor de autorización que deben usar y pueden reenviar secretos al servidor de autorización malicioso (AS Mix-Up Attack). [22] Esto provocó la creación de un nuevo borrador de Internet de mejores prácticas actuales que se propone definir un nuevo estándar de seguridad para OAuth 2.0. [23] Suponiendo que se haya implementado una solución contra el AS Mix-Up Attack, la seguridad de OAuth 2.0 ha sido probada en modelos de atacantes fuertes mediante análisis formal. [22]
Se ha expuesto una implementación de OAuth 2.0 con numerosas fallas de seguridad. [24]
En abril y mayo de 2017, alrededor de un millón de usuarios de Gmail (menos del 0,1% de los usuarios en mayo de 2017) fueron blanco de un ataque de phishing basado en OAuth y recibieron un correo electrónico que supuestamente era de un colega, empleador o amigo que deseaba compartir un documento en Google Docs. [25] Aquellos que hicieron clic en el enlace dentro del correo electrónico fueron dirigidos a iniciar sesión y permitir que un programa de terceros potencialmente malintencionado llamado "Google Apps" acceda a su "cuenta de correo electrónico, contactos y documentos en línea". [25] En "aproximadamente una hora", [25] Google detuvo el ataque de suplantación de identidad (phishing) y recomendó a quienes habían dado acceso a "Google Apps" a su correo electrónico que revoquen dicho acceso y cambien sus contraseñas.
Usos
OAuth se puede utilizar como mecanismo de autorización para acceder a fuentes RSS / ATOM seguras . El acceso a fuentes RSS / ATOM que requieren autenticación siempre ha sido un problema. Por ejemplo, no se pudo acceder a una fuente RSS de un sitio de Google seguro mediante Google Reader . En cambio, se habría utilizado OAuth de tres patas para autorizar a ese cliente RSS a acceder al feed desde el sitio de Google.
También se puede utilizar como un medio para iniciar sesión sin crear una cuenta en ningún sitio y todos los beneficios del host del sistema OAuth.
OAuth y otros estándares
OpenID frente a pseudoautenticación mediante OAuth
OAuth es un protocolo de autorización , en lugar de un protocolo de autenticación . El uso de OAuth por sí solo como método de autenticación puede denominarse pseudoautenticación. [ cita requerida ] Los siguientes diagramas resaltan las diferencias entre el uso de OpenID (diseñado específicamente como un protocolo de autenticación) y OAuth para la autorización.
El flujo de comunicación en ambos procesos es similar:
- (Sin imagen) El usuario solicita un acceso a un recurso o sitio desde la aplicación.
- El sitio ve que el usuario no está autenticado. Formula una solicitud para el proveedor de identidad, la codifica y la envía al usuario como parte de una URL de redireccionamiento.
- El navegador del usuario realiza una solicitud a la URL de redireccionamiento del proveedor de identidad, incluida la solicitud de la aplicación.
- Si es necesario, el proveedor de identidad autentica al usuario (quizás pidiéndole su nombre de usuario y contraseña)
- Una vez que el proveedor de identidad está satisfecho de que el usuario está suficientemente autenticado, procesa la solicitud de la aplicación, formula una respuesta y la envía al usuario junto con una URL de redireccionamiento a la aplicación.
- El navegador del usuario solicita la URL de redireccionamiento que vuelve a la aplicación, incluida la respuesta del proveedor de identidad.
- La aplicación decodifica la respuesta del proveedor de identidad y continúa en consecuencia.
- (Solo OAuth) La respuesta incluye un token de acceso que la aplicación puede usar para obtener acceso directo a los servicios del proveedor de identidad en nombre del usuario.
La diferencia crucial es que en el caso de uso de autenticación OpenID , la respuesta del proveedor de identidad es una afirmación de identidad; mientras que en el caso de uso de autorización de OAuth , el proveedor de identidad también es un proveedor de API , y la respuesta del proveedor de identidad es un token de acceso que puede otorgar a la aplicación acceso continuo a algunas de las API del proveedor de identidad, en nombre del usuario. El token de acceso actúa como una especie de "llave de valet" que la aplicación puede incluir con sus solicitudes al proveedor de identidad, lo que demuestra que tiene permiso del usuario para acceder a esas API .
Debido a que el proveedor de identidad normalmente (pero no siempre) autentica al usuario como parte del proceso de concesión de un token de acceso OAuth, es tentador ver una solicitud de token de acceso OAuth exitosa como un método de autenticación en sí mismo. Sin embargo, debido a que OAuth no fue diseñado con este caso de uso en mente, hacer esta suposición puede conducir a fallas de seguridad importantes. [26]
OAuth y XACML
XACML es un marco de autorización de control de acceso basado en atributos y basado en políticas . Proporciona:
- Una arquitectura de control de acceso .
- Un lenguaje de políticas con el que expresar una amplia gama de políticas de control de acceso, incluidas las políticas que pueden usar consentimientos manejados / definidos a través de OAuth.
- Un esquema de solicitud / respuesta para enviar y recibir solicitudes de autorización.
XACML y OAuth se pueden combinar para ofrecer un enfoque más completo para la autorización. OAuth no proporciona un lenguaje de políticas con el que definir políticas de control de acceso. XACML se puede utilizar por su lenguaje de políticas.
Donde OAuth se enfoca en el acceso delegado (yo, el usuario, otorgo acceso de Twitter a mi muro de Facebook) y la autorización centrada en la identidad, XACML adopta un enfoque basado en atributos que puede considerar los atributos del usuario, la acción, el recurso y el contexto (quién, qué, dónde, cuándo, cómo). Con XACML es posible definir políticas como
- Los gerentes pueden ver documentos en su departamento
- Los administradores pueden editar los documentos que poseen en modo borrador
XACML proporciona un control de acceso más detallado que OAuth. OAuth está limitado en granularidad a la funcionalidad básica (los alcances) expuestos por el servicio de destino. Como resultado, a menudo tiene sentido combinar OAuth y XACML juntos, donde OAuth proporcionará el caso de uso de acceso delegado y la gestión del consentimiento y XACML proporcionará las políticas de autorización que funcionan en las aplicaciones, los procesos y los datos.
Por último, XACML puede funcionar de forma transparente en varias pilas ( API , SSO web, ESB, aplicaciones propias, bases de datos ...). OAuth se centra exclusivamente en aplicaciones basadas en HTTP.
Controversia
Eran Hammer renunció a su cargo de autor principal del proyecto OAuth 2.0, se retiró del grupo de trabajo de IETF y eliminó su nombre de la especificación en julio de 2012. Hammer citó un conflicto entre las culturas web y empresarial como su razón para irse, y señaló que IETF es una comunidad que "se trata de casos de uso empresarial" y "no es capaz de hacerlo de forma simple". "Lo que ahora se ofrece es un anteproyecto para un protocolo de autorización", señaló, "esa es la forma empresarial", proporcionando una "frontera completamente nueva para vender servicios de consultoría y soluciones de integración". [27]
Al comparar OAuth 2.0 con OAuth 1.0, Hammer señala que se ha vuelto "más complejo, menos interoperable, menos útil, más incompleto y, lo más importante, menos seguro". Explica cómo los cambios de arquitectura para los tokens 2.0 no vinculados de los clientes, eliminaron todas las firmas y la criptografía a nivel de protocolo y agregaron tokens con vencimiento (porque los tokens no se podían revocar) al tiempo que complicaban el procesamiento de la autorización. Numerosos elementos se dejaron sin especificar o ilimitados en la especificación porque "como ha sido la naturaleza de este grupo de trabajo, ningún tema es demasiado pequeño para atascarse o dejarlo abierto para que cada implementación lo decida". [27]
Más tarde, David Recordon también eliminó su nombre de las especificaciones por razones no especificadas. Dick Hardt asumió la función de editor y el marco se publicó en octubre de 2012. [12]
Ver también
- Lista de proveedores de OAuth
- Portabilidad de datos
- IndieAuth
- Persona de Mozilla
- OpenID
- SAML
- XACML
- Acceso administrado por el usuario
Referencias
- ^ Whitson, Gordon. "Comprensión de OAuth: qué sucede cuando inicia sesión en un sitio con Google, Twitter o Facebook" . Lifehacker . Archivado desde el original el 24 de abril de 2014 . Consultado el 15 de mayo de 2016 .
- ^ Henry, Gavin (enero de 2020). "Justin Richer en OAuth" . Software IEEE . 37 (1): 98–100. doi : 10.1109 / MS.2019.2949648 . ISSN 0740-7459 .
- ^ "Amazon y OAuth 2.0" . Archivado desde el original el 8 de diciembre de 2017 . Consultado el 15 de diciembre de 2017 .
- ^ "RFC 6749 - El marco de autorización de OAuth 2.0" . Archivado desde el original el 14 de mayo de 2016 . Consultado el 15 de mayo de 2016 .
- ^ "Introducción" . oauth.net . Archivado desde el original el 21 de noviembre de 2018 . Consultado el 21 de noviembre de 2018 .
- ^ "OAuth Core 1.0" . 4 de diciembre de 2007. Archivado desde el original el 25 de noviembre de 2015 . Consultado el 16 de octubre de 2014 .
- ^ Chris Crum (31 de agosto de 2010). "Las aplicaciones de Twitter se convierten en OAuth hoy" . WebProNews.com . Archivado desde el original el 31 de julio de 2017 . Consultado el 31 de julio de 2017 .
- ^ "Protocolo de autorización web (oauth)" . Grupo de trabajo de ingeniería de Internet . Archivado desde el original el 2 de julio de 2014 . Consultado el 8 de mayo de 2013 .
- ^ "Autenticación - Desarrolladores de Facebook" . Facebook para desarrolladores . Archivado desde el original el 23 de enero de 2014 . Consultado el 5 de enero de 2020 .
- ^ "Uso de OAuth 2.0 para acceder a las API de Google | Plataforma de identidad de Google" . Desarrolladores de Google . Archivado desde el original el 4 de enero de 2020 . Consultado el 4 de enero de 2020 .
- ^ "Protocolos v2.0 - Flujo de código de autorización OAuth 2.0" . Microsoft Docs . Archivado desde el original el 29 de junio de 2020 . Consultado el 29 de junio de 2020 .
- ^ a b Hardt, Dick (octubre de 2012). "RFC6749 - El marco de autorización de OAuth 2.0" . Grupo de trabajo de ingeniería de Internet . Archivado desde el original el 15 de octubre de 2012 . Consultado el 10 de octubre de 2012 .
- ^ Jones, Michael; Hardt, Dick (octubre de 2012). "RFC6750 - El marco de autorización de OAuth 2.0: uso de token de portador" . Grupo de trabajo de ingeniería de Internet . Archivado desde el original el 15 de octubre de 2012 . Consultado el 10 de octubre de 2012 .
- ^ Lodderstedt, Torsten; Hardt, Dick; Parecki, Aaron. "El marco de autorización OAuth 2.1" . tools.ietf.org . Consultado el 22 de noviembre de 2020 .
- ^ "Aviso de seguridad de OAuth: 2009.1" . oauth.net . 23 de abril de 2009. Archivado desde el original el 27 de mayo de 2016 . Consultado el 23 de abril de 2009 .
- ^ "OAuth Core 1.0a" . oauth.net . Archivado desde el original el 30 de junio de 2009 . Consultado el 17 de julio de 2009 .
- ^ Lodderstedt, Torsten; McGloin, Mark; Hunt, Phil (enero de 2013). "RFC6819 - Modelo de amenazas OAuth 2.0 y consideraciones de seguridad" . Grupo de trabajo de ingeniería de Internet . Archivado desde el original el 30 de junio de 2020 . Consultado el 29 de junio de 2020 .[rfc: 6819 OAuth 2.0 Modelo de amenazas y consideraciones de seguridad]. Grupo de Trabajo de Ingeniería de Internet. Consultado en enero de 2015.
- ^ "Aviso de seguridad de OAuth: 2014.1" Redireccionamiento encubierto " " . oauth.net . 4 de mayo de 2014. Archivado desde el original el 21 de noviembre de 2015 . Consultado el 10 de noviembre de 2014 .
- ^ "Seria falla de seguridad en OAuth, OpenID descubierto" . CNET . 2 de mayo de 2014. Archivado desde el original el 2 de noviembre de 2015 . Consultado el 10 de noviembre de 2014 .
- ^ "Estudiante de matemáticas detecta OAuth, vulnerabilidad de seguridad OpenID" . Phys.org. 3 de mayo de 2014. Archivado desde el original el 6 de noviembre de 2015 . Consultado el 11 de noviembre de 2014 .
- ^ "Redirección encubierta" . Tetraph. 1 de mayo de 2014. Archivado desde el original el 10 de marzo de 2016 . Consultado el 10 de noviembre de 2014 .
- ^ a b Fett, Daniel; Küsters, Ralf; Schmitz, Guido (2016). "Un análisis de seguridad formal integral de OAuth 2.0". Actas de la Conferencia ACM SIGSAC 2016 sobre seguridad informática y de comunicaciones - CCS'16 . Nueva York, Nueva York, EE. UU.: ACM Press: 1204–1215. arXiv : 1601.01229 . Código Bib : 2016arXiv160101229F . doi : 10.1145 / 2976749.2978385 . ISBN 9781450341394. S2CID 1723789 .
- ^ Bradley, John; Labunets, Andrey; Lodderstedt, Torsten; Fett, Daniel. "Mejores prácticas actuales de seguridad de OAuth 2.0" . Grupo de trabajo de ingeniería de Internet . Archivado desde el original el 17 de enero de 2020 . Consultado el 29 de julio de 2019 .
- ^ "Hackear Facebook con OAuth 2.0 y Chrome" . 12 de febrero de 2013. Archivado desde el original el 23 de abril de 2016 . Consultado el 6 de marzo de 2013 .
- ^ a b c "El correo electrónico de phishing de Google Docs 'costó a Minnesota $ 90.000 ' " . BBC News . 8 de mayo de 2017. Archivado desde el original el 30 de junio de 2020 . Consultado el 29 de junio de 2020 .
- ^ "Autenticación del usuario final con OAuth 2.0" . oauth.net . Archivado desde el original el 19 de noviembre de 2015 . Consultado el 8 de marzo de 2016 .
- ^ a b Hammer, Eran (28 de julio de 2012). "OAuth 2.0 y el camino al infierno" . Hueniverse . Archivado desde el original el 25 de marzo de 2013 . Consultado el 17 de enero de 2018 .
enlaces externos
- Página web oficial
- Lista de correo del Grupo de trabajo de OAuth
- El protocolo OAuth 1.0 (RFC 5849)
- El marco de autorización de OAuth 2.0 (RFC 6749)
- Marco de autorización de OAuth 2.0: uso de token de portador (RFC 6750)
- El marco de autorización de OAuth 2.1 draft-ietf-oauth-v2-1-00
- Centro de recursos y guía para principiantes de OAuth de Hueniverse en Wayback Machine (archivado el 20 de febrero de 2017)
- Hoja de referencia de puntos finales de OAuth
- OAuth con la integración del marco de Spring