Hispanopedia Wiki
Articulo de referencia

OAuth

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

Hispanopedia WikiContenido en espanolLectura gratuita

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 proporciona a los propietarios de recursos una forma de otorgar a una aplicación cliente 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 permite que un servidor de autorización emita tokens de acceso a clientes de terceros, con la aprobación del propietario del recurso. El tercero utiliza entonces el token de acceso para acceder a los recursos protegidos alojados por el servidor de recursos. [ 2 ]

Historia

Flujo de autorización sin OAuth.
Un flujo de autorización hipotético donde la información de inicio de sesión se comparte con una aplicación de terceros. Esto plantea numerosos riesgos de seguridad que pueden prevenirse mediante el uso de flujos de autorización OAuth.
Descripción general del flujo de autorización de OAuth 2.0.
Descripción general del flujo de OAuth 2.0. Las credenciales del propietario del recurso se utilizan únicamente en el servidor de autorización, pero no en el cliente (por ejemplo, la aplicación de terceros).

OAuth comenzó en noviembre de 2006 cuando Blaine Cook estaba desarrollando una implementación de OpenID para Twitter . Mientras tanto, Magnolia necesitaba una solución para permitir que sus miembros con OpenID autorizaran los widgets del Dashboard de Mac OS X 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 existían estándares abiertos para la delegación de acceso a la API. [ 6 ]

El grupo de discusión de OAuth se creó en abril de 2007 para que un pequeño grupo de implementadores redactara la propuesta preliminar de un protocolo abierto. DeWitt Clinton, de Google , se enteró del proyecto OAuth y expresó su interés en apoyarlo. En julio de 2007, el equipo redactó una especificación inicial. Eran Hammer se unió y coordinó las numerosas contribuciones a OAuth, creando una especificación más formal. El 3 de octubre 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, por sus siglas en inglés), celebrada en Minneapolis en noviembre de 2008, se llevó a cabo una sesión informal sobre OAuth para debatir la incorporación del protocolo al IETF y su posterior estandarización. El evento contó con una nutrida asistencia y un amplio respaldo 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 informativa de comentarios , en abril de 2010. Desde el 31 de agosto de 2010, todas las aplicaciones de terceros de Twitter están obligadas a usar OAuth. [ 7 ]

El marco OAuth 2.0 se publicó considerando casos de uso adicionales y requisitos de extensibilidad recopilados de la comunidad IETF en general. 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 la especificación de uso de tokens de portador como RFC 6750 ; ambos estándares siguen el proceso de Solicitudes de comentarios (Requests for Comments) en octubre de 2012. [ 2 ] [ 8 ]

A fecha de noviembre de 2024, el borrador del marco de autorización OAuth 2.1 se encuentra en desarrollo. Consolida la funcionalidad de los RFC OAuth 2.0, OAuth 2.0 para aplicaciones nativas, prueba de clave para intercambio de código, OAuth 2.0 para aplicaciones basadas en navegador, OAuth Security Best Current y uso de tokens de portador. [ 9 ]

Problemas de seguridad

OAuth 1.0

El 23 de abril de 2009 se anunció una vulnerabilidad de seguridad de fijación de sesión en el protocolo 1.0. Afecta al flujo de autorización OAuth (también conocido como "OAuth de 3 pasos") en la Sección 6 de OAuth Core 1.0. [ 10 ] Se publicó la versión 1.0a del protocolo OAuth Core para solucionar este problema. [ 11 ]

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. [ 12 ] 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". [ 13 ] [ 14 ] [ 15 ] [ 16 ]

OAuth 2.0 se ha analizado mediante análisis formal de protocolos web. Este análisis reveló que en configuraciones con múltiples servidores de autorización, uno de los cuales se comporta de forma maliciosa, los clientes pueden confundirse sobre qué servidor de autorización usar y podrían reenviar secretos al servidor de autorización malicioso (ataque de confusión de AS). [ 17 ] Esto impulsó la creación de un nuevo borrador de buenas prácticas de Internet que busca definir un nuevo estándar de seguridad para OAuth 2.0. [ 18 ] Suponiendo que exista una solución contra el ataque de confusión de AS, la seguridad de OAuth 2.0 se ha demostrado bajo modelos de atacantes robustos mediante análisis formal. [ 17 ]

Se ha descubierto una implementación de OAuth 2.0 con numerosas fallas de seguridad. [ 19 ]

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, recibiendo un correo electrónico que supuestamente provenía de un colega, empleador o amigo que quería compartir un documento en Google Docs. [ 20 ] Quienes hicieron clic en el enlace 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". [ 20 ] En "aproximadamente una hora", [ 20 ] el ataque de phishing fue detenido por Google, que 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 recomendó el uso de la extensión PKCE ( RFC  7636  ) para aplicaciones nativas a todo tipo de clientes OAuth, incluidas las aplicaciones web y otros  clientes confidenciales, con el fin de evitar que extensiones maliciosas del navegador realicen ataques de inyección de código OAuth 2.0. [ 9 ]

Tipos

El marco OAuth especifica varios tipos de concesión para diferentes casos de uso. Algunos de los tipos de concesión OAuth más comunes son: [ 21 ]

  • Código de autorización
  • PKCE
  • Credenciales del cliente
  • Código del dispositivo
  • Token de actualización
  • Credenciales de contraseña del propietario del recurso (ROPC)

Usos

La API Graph de Facebook solo admite OAuth 2.0. [ 22 ] Google admite OAuth 2.0 como el mecanismo de autorización recomendado para todas sus API . [ 23 ] Microsoft también admite OAuth 2.0 para varias API y su servicio Azure Active Directory, [ 24 ] que se utiliza para proteger muchas API de Microsoft y de terceros.

OAuth puede utilizarse 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 podía acceder a una fuente RSS de un sitio seguro de Google mediante Google Reader . En su lugar, se utilizaba OAuth de tres pasos para autorizar a ese cliente RSS a acceder a la fuente del sitio de Google.

Las implementaciones de software libre del protocolo OAuth2, como la extensión OAuth2OOo de LibreOffice, permiten acceder a recursos remotos (por ejemplo, a través de la API de Google o la API de Microsoft Graph y OAuth 2.0) e incluso, posiblemente, con el lenguaje LibreOffice Basic . Esto facilita enormemente la escritura y el uso de solicitudes HTTP compatibles con el protocolo OAuth 2.0 en las macros de LibreOffice .

OAuth y otros estándares

OAuth es un servicio complementario y distinto de OpenID . OAuth no guarda relación 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 guarda relación con XACML , que es un estándar de políticas 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).

OpenID frente a la pseudoautenticación mediante OAuth

OAuth es un protocolo de autorización , no de autenticación . El uso de OAuth como método de autenticación se denomina pseudoautenticación. [ 25 ] Los siguientes diagramas ilustran 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:

  1. (No se muestra en la imagen) El usuario solicita un acceso a un recurso o sitio web desde la aplicación.
  2. El sitio web detecta que el usuario no está autenticado. Formula una solicitud al proveedor de identidad, la codifica y la envía al usuario como parte de una URL de redireccionamiento.
  3. El navegador del usuario realiza una solicitud a la URL de redireccionamiento del proveedor de identidad, incluida la solicitud de la aplicación.
  4. Si es necesario, el proveedor de identidad autentica al usuario (quizás solicitándole su nombre de usuario y contraseña).
  5. Una vez que el proveedor de identidad comprueba que el usuario está suficientemente autenticado, procesa la solicitud de la aplicación, formula una respuesta y la envía de vuelta al usuario junto con una URL de redireccionamiento a la aplicación.
  6. El navegador del usuario solicita la URL de redireccionamiento que regresa a la aplicación, incluida la respuesta del proveedor de identidad.
  7. La aplicación decodifica la respuesta del proveedor de identidad y procede en consecuencia.
  8. (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 radica en 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 su respuesta 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, lo que demuestra que tiene permiso del usuario para acceder a esas API.

Dado que el proveedor de identidades normalmente (aunque no siempre) autentica al usuario como parte del proceso de concesión 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 se diseñó teniendo en cuenta este caso de uso, asumir esto puede generar importantes fallos de seguridad. [ 26 ]

OpenID frente a pseudoautenticación mediante OAuth

OAuth y XACML

XACML es un marco de autorización de control de acceso basado en políticas y atributos . Proporciona:

  • Una arquitectura de control de acceso .
  • Un lenguaje de políticas que permite expresar una amplia gama de políticas de control de acceso, incluidas aquellas que pueden utilizar consentimientos gestionados/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 de autorización. OAuth no proporciona un lenguaje de políticas para definir las políticas de control de acceso. XACML puede utilizarse como lenguaje de políticas.

Mientras que OAuth se centra en el acceso delegado (yo, el usuario, otorgo a Twitter acceso a mi muro de Facebook) y la autorización centrada en la identidad, XACML adopta un enfoque basado en atributos que puede considerar 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 los documentos en su departamento.
  • Los administradores pueden editar los documentos de su propiedad en modo borrador.

XACML proporciona un control de acceso más detallado que OAuth. OAuth se limita a la funcionalidad general (los ámbitos) que expone el servicio de destino. Por lo tanto, suele ser conveniente combinar OAuth y XACML, donde OAuth proporciona el acceso delegado y la gestión del consentimiento, y XACML proporciona las políticas de autorización que se aplican a las aplicaciones, los procesos y los datos.

Por último, XACML puede funcionar de forma transparente en múltiples plataformas ( 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 como autor principal del proyecto OAuth 2.0, se retiró del grupo de trabajo de la IETF y eliminó su nombre de la especificación en julio de 2012. Hammer citó un conflicto entre las culturas web y empresarial como la razón de su partida, señalando que la IETF es una comunidad que se centra exclusivamente en los casos de uso empresarial y que no es capaz de simplificar. «Lo que se ofrece ahora es un modelo para un protocolo de autorización», señaló, «que es la forma empresarial», lo que proporciona «una nueva frontera 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 arquitectónicos para 2.0 eliminaron los tokens de los clientes, suprimieron todas las firmas y la criptografía a nivel de protocolo y añadieron tokens que caducan (porque los tokens no se podían revocar), lo que complicó el procesamiento de la autorización. Numerosos elementos quedaron sin especificar o ilimitados en la especificación porque "como ha sido la naturaleza de este grupo de trabajo, ningún problema es demasiado pequeño como para quedarse estancado en él o dejarlo abierto para que cada implementación decida". [ 27 ]

Posteriormente, David Recordon también retiró su nombre de las especificaciones por razones no especificadas. 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 auténtico desastre", ya que requiere que los desarrolladores escriban módulos personalizados específicos para cada servicio (Gmail, servicios de correo de Microsoft, etc.) y se registren específicamente con ellos. [ 28 ]

Véase también

Referencias

  1. ↑ "Autorización abierta - Glosario | CSRC" . Centro de recursos de seguridad informática del NIST . Archivado del original el 21 de septiembre de 2022. Consultado el 23 de julio de 2021 .
  2. 1 2 3 4 Hardt, Dick (octubre de 2012). Hardt, D (ed.). "RFC6749 - El marco de autorización OAuth 2.0" . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6749 . Archivado del original el 15 de octubre de 2012. Recuperado el 10 de octubre de 2012 .
  3. ↑ Whitson, Gordon. "Entendiendo OAuth: Qué sucede cuando inicias sesión en un sitio con Google, X o Facebook" . Lifehacker . Archivado del original el 24 de abril de 2014. Recuperado el 15 de mayo de 2016 .
  4. ↑ Henry, Gavin (enero de 2020). "Justin Richer sobre OAuth" . IEEE Software . 37 (1): 98–100 . doi : 10.1109/MS.2019.2949648 . ISSN 0740-7459 . 
  5. ↑ "Amazon y OAuth 2.0" . Archivado del original el 8 de diciembre de 2017. Consultado el 15 de diciembre de 2017 .
  6. 1 2 "Introducción a OAuth" . Archivado del original el 1 de abril de 2026. Recuperado el 1 de abril de 2026 .
  7. ↑ Chris Crum (31 de agosto de 2010). "Las aplicaciones de Twitter adoptan OAuth hoy" . WebProNews . Archivado del original el 31 de julio de 2017. Consultado el 31 de julio de 2017 .
  8. ↑ Jones, Michael; Hardt, Dick (octubre de 2012). "RFC6750 - El marco de autorización OAuth 2.0: uso de tokens de portador" . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6750 . Archivado del original el 15 de octubre de 2012. Recuperado el 10 de octubre de 2012 .
  9. 1 2 Lodderstedt, Torsten; Hardt, Dick; Parecki, Aaron (15 de noviembre de 2024). "El marco de autorización OAuth 2.1" . tools.ietf.org . Recuperado el 19 de diciembre de 2024 .
  10. ↑ "Aviso de seguridad de OAuth: 2009.1" . Sitio de la comunidad de OAuth . 23 de abril de 2009. Archivado del original el 27 de mayo de 2016. Consultado el 23 de abril de 2009 .
  11. ↑ "OAuth Core 1.0a" . Sitio de la comunidad OAuth . Archivado del original el 30 de junio de 2009. Consultado el 17 de julio de 2009 .
  12. ↑ Lodderstedt, Torsten; McGloin, Mark; Hunt, Phil (enero de 2013). Lodderstedt, T (ed.). "RFC6819 - Modelo de amenazas y consideraciones de seguridad de OAuth 2.0" . Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6819 . Archivado del original el 30 de junio de 2020. Recuperado el 29 de junio de 2020 .[rfc:6819 Modelo de amenazas y consideraciones de seguridad de OAuth 2.0]. Grupo de trabajo de ingeniería de Internet. Consultado en enero de 2015.
  13. ↑ "Aviso de seguridad de OAuth: 2014.1 "Redirección encubierta"" . Sitio de la comunidad OAuth . 4 de mayo de 2014. Archivado del original el 21 de noviembre de 2015. Consultado el 10 de noviembre de 2014 .
  14. ↑ "Se descubre una grave vulnerabilidad de seguridad en OAuth y OpenID" . CNET . 2 de mayo de 2014. Archivado del original el 2 de noviembre de 2015. Consultado el 10 de noviembre de 2014 .
  15. ↑ "Estudiante de matemáticas detecta vulnerabilidad de seguridad en OAuth y OpenID" . Phys.org. 3 de mayo de 2014. Archivado del original el 6 de noviembre de 2015. Consultado el 11 de noviembre de 2014 .
  16. ↑ "Redirección encubierta" . Tetraph. 1 de mayo de 2014. Archivado del original el 10 de marzo de 2016. Consultado el 10 de noviembre de 2014 .
  17. 1 2 Fett, Daniel; Küsters, Ralf; Schmitz, Guido (2016). "Un análisis formal exhaustivo de seguridad de OAuth 2.0". Actas de la Conferencia ACM SIGSAC de 2016 sobre seguridad informática y de comunicaciones . Nueva York, Nueva York, EE. UU.: ACM Press. págs. 1204–1215 . arXiv : 1601.01229 . Bibcode : 2016arXiv160101229F . doi : 10.1145/2976749.2978385 . ISBN  9781450341394. S2CID 1723789 . 
  18. ↑ Bradley, John; Labunets, Andrey; Lodderstedt, Torsten; Fett, Daniel (8 de julio de 2019). "Mejores prácticas actuales de seguridad de OAuth 2.0" . Grupo de trabajo de ingeniería de Internet . Archivado del original el 17 de enero de 2020. Recuperado el 29 de julio de 2019 .
  19. ↑ "Hackeando Facebook con OAuth 2.0 y Chrome" . 12 de febrero de 2013. Archivado del original el 23 de abril de 2016. Consultado el 6 de marzo de 2013 .
  20. 1 2 3 "Un correo electrónico de phishing de Google Docs le costó a Minnesota 90.000 dólares"BBC News . 8 de mayo de 2017. Archivado del original el 30 de junio de 2020. Consultado el 29 de junio de 2020 .
  21. ↑ "Tipos de concesión de OAuth" . Oauth.net . Consultado el 6 de diciembre de 2023 .
  22. ↑ "Autenticación - Facebook Developers" . Facebook para desarrolladores . Archivado del original el 23 de enero de 2014. Consultado el 5 de enero de 2020 .
  23. ↑ "Uso de OAuth 2.0 para acceder a las API de Google | Plataforma de identidad de Google" . Google Developers . Archivado del original el 4 de enero de 2020. Consultado el 4 de enero de 2020 .
  24. ↑ "Protocolos v2.0 - Flujo de código de autorización OAuth 2.0" . Microsoft Docs . Archivado del original el 29 de junio de 2020. Consultado el 29 de junio de 2020 .
  25. ↑ "Introducción a la autenticación OAuth2" . Akamai Connected Cloud . 22 de octubre de 2021. Archivado del original el 18 de abril de 2024. Consultado el 18 de abril de 2024 .
  26. ↑ "Autenticación de usuario final con OAuth 2.0" . Sitio de la comunidad de OAuth . Archivado del original el 19 de noviembre de 2015. Consultado el 8 de marzo de 2016 .
  27. 1 2 Hammer, Eran (28 de julio de 2012). "OAuth 2.0 y el camino al infierno" . Hueniverse . Archivado del original el 25 de marzo de 2013. Recuperado el 17 de enero de 2018 .
  28. ↑ Harris, David (octubre de 2021). "Octubre de 2021: actualizaciones y garantías" . Pegasus Mail . Archivado del original el 16 de enero de 2024. Consultado el 19 de diciembre de 2024 .
Lecturas relacionadas
6 articulos
Estándar abiertoEstándar abiertoUn estándar abierto es un estándar que es de libre acceso y utilizable por cualquier persona. También es un requisito previo común que los estándar...Amazon (empresa)Amazon (empresa)Amazon.com, Inc. , [1] que opera como Amazon ( / ˈæməzɒn / , AM - ə-zon ; en .mw-parser-output .IPA-label-small{font-size:85%}.mw-parser-output .re...Cada letra de "Google" está coloreada (de izquierda a derecha) en azul, rojo, amarillo, azul, verde y rojo.GoogleGoogle LLC ( / ˈ ɡ uː ɡ ə l / Google ( GOO-ghəlcorporación multinacionalestadounidenseyuna empresa de tecnologíacentrada enla publicidad en línea,l...Meta PlatformsMeta PlatformsMeta Platforms, Inc.,[10] doing business as Meta,[11] and formerly named Facebook, Inc., and TheFacebook, Inc.,[12][13] is an American multinationa...MicrosoftMicrosoftMicrosoft Corporation es una corporación multinacional y empresa de tecnología estadounidense con sede en Redmond, Washington . [2] Sus productos d...GorjeoGorjeoTwitter , oficialmente conocido como X desde julio de 2023, es un servicio de redes sociales . Es uno de los sitios web de redes sociales más grand...