OAuth (abreviatura de autorización abierta [1] [2] ) 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. [3] [4] Este mecanismo es utilizado por empresas como Amazon , [5] Google , Meta Platforms , Microsoft y Twitter para permitir que los usuarios compartan información sobre sus cuentas con aplicaciones o sitios web de terceros.
En general, el protocolo OAuth ofrece una forma para que los propietarios de recursos proporcionen a una aplicación cliente un acceso delegado seguro a los recursos del servidor. Especifica un proceso para que los propietarios de recursos autoricen el acceso de terceros a sus recursos del servidor sin proporcionar credenciales. Diseñado específicamente para funcionar con el Protocolo de transferencia de hipertexto (HTTP), OAuth básicamente 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 utiliza el token de acceso para acceder a los recursos protegidos alojados por el servidor de recursos. [2]
OAuth comenzó en noviembre de 2006, cuando Blaine Cook estaba desarrollando la implementación de OpenID para Twitter . Mientras tanto, Ma.gnolia necesitaba una solución que permitiera a sus miembros con OpenID autorizar a los widgets del Dashboard a acceder a su servicio. Cook, Chris Messina y Larry Halff de Magnolia se reunieron con David Recordon para hablar sobre el uso de OpenID con las API de Twitter y Magnolia para delegar la autenticación. Llegaron a la conclusión de que no existían estándares abiertos para la delegación de acceso a las API. [6]
El grupo de discusión de OAuth se creó en abril de 2007 para que un pequeño grupo de implementadores escribiera el borrador de la propuesta de un protocolo abierto. DeWitt Clinton, de Google , se enteró del proyecto OAuth y expresó su interés en apoyar la iniciativa. En julio de 2007, el equipo redactó una especificación inicial. Eran Hammer se unió y coordinó las numerosas 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. [7]
En la 73.ª reunión del Grupo de trabajo sobre ingeniería de Internet (IETF) celebrada en Minneapolis en noviembre de 2008, se celebró un Foro de debate sobre OAuth para debatir la incorporación del protocolo al IETF con miras a un mayor trabajo de normalización. El evento tuvo una buena asistencia y hubo un amplio apoyo a la creación formal de un grupo de trabajo sobre 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. [8]
El marco OAuth 2.0 se publicó teniendo en cuenta casos de uso adicionales y requisitos de extensibilidad recopilados de la comunidad IETF más amplia. Si bien se basa en la experiencia de implementación de OAuth 1.0, OAuth 2.0 no es compatible con versiones anteriores de OAuth 1.0. OAuth 2.0 se publicó como RFC 6749 y el Bearer Token Usage [ aclaración necesaria ] como RFC 6750, ambos estándares siguen las solicitudes de comentarios, en octubre de 2012. [2] [9]
El marco de autorización OAuth 2.1 está en etapa de borrador y consolida la funcionalidad de las RFC OAuth 2.0, OAuth 2.0 para aplicaciones nativas, clave de prueba para intercambio de código, OAuth 2.0 para aplicaciones basadas en navegador, OAuth Security Best Current y Bearer Token Usage. [10]
El 23 de abril de 2009, se anunció una falla de seguridad en la fijación de sesiones en el protocolo 1.0. Afecta al flujo de autorización OAuth (también conocido como "OAuth de tres vías") en la Sección 6 de OAuth Core 1.0. [11] La versión 1.0a del protocolo OAuth Core se publicó para solucionar este problema. [12]
En enero de 2013, el Grupo de Trabajo de Ingeniería de Internet publicó un modelo de amenazas para OAuth 2.0. [13] Entre las amenazas descritas se encuentra una llamada "Open Redirector"; a principios de 2014, Wang Jing describió una variante de esta con el nombre de "Covert Redirect". [14] [15] [16] [17]
OAuth 2.0 se ha analizado mediante un análisis formal del protocolo web. 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 sobre el servidor de autorización que deben usar y pueden reenviar secretos al servidor de autorización malicioso (ataque AS Mix-Up). [18] Esto impulsó 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. [19] Suponiendo que se implemente una solución contra el ataque AS Mix-Up, la seguridad de OAuth 2.0 se ha demostrado bajo modelos de atacantes fuertes mediante análisis formal. [18]
Se ha expuesto una implementación de OAuth 2.0 con numerosos fallos de seguridad. [20]
En abril y mayo de 2017, cerca 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, recibiendo un correo electrónico que pretendía ser de un colega, empleador o amigo que quería compartir un documento en Google Docs. [21] 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 malicioso llamado "Google Apps" accediera a su "cuenta de correo electrónico, contactos y documentos en línea". [21] En "aproximadamente una hora", [21] Google detuvo el ataque de phishing y aconsejó a quienes habían dado acceso a "Google Apps" a su correo electrónico que revocaran dicho acceso y cambiaran sus contraseñas.
En el borrador de OAuth 2.1 se ha recomendado el uso de la extensión PKCE para aplicaciones nativas para todo tipo de clientes OAuth, incluidas aplicaciones web y otros clientes confidenciales, con el fin de evitar que extensiones de navegador maliciosas realicen ataques de inyección de código OAuth 2.0. [10]
El marco de OAuth especifica varios tipos de concesión para diferentes casos de uso. Algunos de los tipos de concesión de OAuth más comunes son: [22]
La API Graph de Facebook solo admite OAuth 2.0. [23] Google admite OAuth 2.0 como el mecanismo de autorización recomendado para todas sus API . [24] Microsoft también admite OAuth 2.0 para varias API y su servicio Azure Active Directory, [25] que se utiliza para proteger muchas API de Microsoft y de terceros.
OAuth se puede utilizar como mecanismo de autorización para acceder a feeds RSS / Atom seguros . El acceso a feeds RSS/ATOM que requieren autenticación siempre ha sido un problema. Por ejemplo, no se podría haber accedido a un feed RSS de un sitio seguro de Google mediante Google Reader . En su lugar, se habría utilizado OAuth de tres vías para autorizar a ese cliente RSS a acceder al feed desde el sitio de Google.
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íticas de autorización. OAuth se puede utilizar junto con XACML, donde OAuth se utiliza para el consentimiento de propiedad y la delegación de acceso, mientras que XACML se utiliza para definir las políticas de autorización (por ejemplo, los administradores pueden ver documentos en su región).
OAuth es un protocolo de autorización , no de autenticación . El uso de OAuth como método de autenticación puede denominarse pseudoautenticación. [26] Los siguientes diagramas resaltan las diferencias entre el uso de OpenID (diseñado específicamente como protocolo de autenticación) y OAuth para la autorización.
El flujo de comunicación en ambos procesos es similar:
La diferencia fundamental 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 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 "clave de valet" que la aplicación puede incluir en sus solicitudes al proveedor de identidad, que prueban que tiene permiso del usuario para acceder a esas API.
Dado que el proveedor de identidad normalmente (pero no siempre) autentica al usuario como parte del proceso de otorgamiento de un token de acceso OAuth, resulta tentador considerar una solicitud exitosa de token de acceso OAuth como un método de autenticación en sí mismo. Sin embargo, dado que OAuth no fue diseñado con este caso de uso en mente, hacer esta suposición puede conducir a importantes fallas de seguridad. [27]
XACML es un marco de autorización de control de acceso basado en políticas y atributos . Proporciona:
XACML y OAuth se pueden combinar para ofrecer un enfoque más integral de la autorización. OAuth no proporciona un lenguaje de políticas con el que definir políticas de control de acceso. Se puede utilizar XACML para su lenguaje de políticas.
Mientras que OAuth se centra en el acceso delegado (yo, el usuario, concedo 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
XACML proporciona un control de acceso más detallado que OAuth. OAuth está limitado en granularidad a la funcionalidad básica (los ámbitos) expuesta por el servicio de destino. Como resultado, a menudo tiene sentido combinar OAuth y XACML, donde OAuth proporcionará el caso de uso de acceso delegado y la gestión de consentimientos, 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 múltiples stacks ( API , SSO web, ESB, aplicaciones locales, bases de datos, etc.). OAuth se centra exclusivamente en aplicaciones basadas en HTTP.
Eran Hammer renunció a su rol 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, señalando que IETF es una comunidad que "se trata de casos de uso empresarial" y "no es capaz de ser simple". "Lo que ahora se ofrece es un modelo para un protocolo de autorización", señaló, "que es la forma empresarial", proporcionando una "frontera completamente nueva para vender servicios de consultoría y soluciones de integración". [28] 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 arquitectónicos para 2.0 liberaron tokens de los clientes, eliminaron todas las firmas y criptografía a nivel de protocolo y agregaron tokens que expiraban (porque los tokens no se podían revocar) al tiempo que complicaban el procesamiento de la autorización. Numerosos elementos quedaron sin especificar o fueron ilimitados en la especificación porque "como ha sido la naturaleza de este grupo de trabajo, ningún problema es demasiado pequeño para quedarse estancado en él o dejarlo abierto para que cada implementación lo decida". [28]
David Recordon luego también eliminó su nombre de las especificaciones por razones no especificadas. [ cita requerida ] Dick Hardt asumió el rol de editor y el marco se publicó en octubre de 2012. [2]
David Harris, autor del cliente de correo electrónico Pegasus Mail , ha criticado OAuth 2.0 como "un completo desastre", que requiere que los desarrolladores escriban módulos personalizados específicos para cada servicio (Gmail, servicios de Microsoft Mail, etc.) y se registren específicamente en ellos. [29]
{{cite journal}}: Requiere citar revista |journal=( ayuda ){{cite journal}}: Requiere citar revista |journal=( ayuda )