| OAuth | |
|---|---|
| Nombre | OAuth |
| Archivos multimedia en Wikimedia Commons | |
OAuth es un protocolo (esquema) de autorización abierto que proporciona a un tercero acceso limitado a los recursos protegidos del usuario sin transferirle un nombre de usuario y una contraseña (al tercero) [1] [2] .
El trabajo en el protocolo comenzó en noviembre de 2006 y la última versión de OAuth 1.0 se aprobó el 4 de diciembre de 2007. Como desarrollo posterior, en 2010 apareció el protocolo OAuth 2.0, cuya última versión se publicó en octubre de 2012 como RFC 6749 .
Uno de los problemas de autenticación y seguridad de la información es que los usuarios suelen utilizar varios servicios diferentes (por ejemplo, en Google, Twitter, Apple , etc.) y, en consecuencia, varias cuentas con sus propios nombres de usuario y contraseñas. Por lo tanto, los usuarios necesitan almacenar y proteger muchos inicios de sesión y contraseñas. Dado que cada uno de los servicios tiene su propio sistema de seguridad con sus propias vulnerabilidades y deficiencias, todo esto va en detrimento de la comodidad y seguridad de los usuarios. Por ejemplo, si los usuarios usan las mismas contraseñas para diferentes servicios, luego de obtener acceso a una de las cuentas, el procedimiento de piratería de otras cuentas para los atacantes se simplifica enormemente [3] .
La autenticación en dos pasos (por ejemplo , Google Authenticator ) se puede utilizar para aumentar la seguridad, cuando se utiliza otro servicio de usuario para la confirmación (por ejemplo, cuando se requiere un código enviado a un teléfono móvil para la autenticación en un sitio web ). Con este enfoque, la probabilidad de piratería se reduce significativamente. La característica clave del uso de OAuth es que si el usuario tiene una cuenta bien protegida, con la ayuda de esta y la tecnología OAuth, puede autenticarse en otros servicios, mientras que el usuario no necesita revelar su contraseña principal. Por ejemplo, un usuario que quiera dar acceso a un servicio de impresión de fotos en línea a las fotos de su cuenta de Facebook no necesita proporcionar al servicio la contraseña de esa cuenta. En su lugar, pasa la autorización a Facebook, que (con el permiso del usuario o del administrador del servicio) ya proporciona el servicio de impresión en línea con el acceso necesario a las fotos [3] .
OAuth apareció en noviembre de 2006, durante el desarrollo del protocolo OpenID para el servicio de microblogging Twitter de Blaine Cook . Junto con Chris Messina , estaba buscando una forma de usar OpenID para proporcionar acceso a la API de Twitter sin dar una contraseña al servicio. En colaboración con el cocreador de OpenID, David Recordon , analizaron la funcionalidad de OpenID, así como los protocolos de autorización patentados , como Flickr Auth , Google AuthSub y Yahoo! BBAuth , después de lo cual llegaron a la conclusión de que se necesita un nuevo protocolo abierto [4] .
En abril de 2007 se formó un grupo de ingenieros para trabajar en su creación. En su trabajo participaron empleados de Google y AOL (que al mismo tiempo introdujeron su propio protocolo OpenAuth ). La versión final del núcleo del protocolo OAuth 1.0 se lanzó el 4 de diciembre de 2007. En 2008 se trabajó en la estandarización del protocolo en el Internet Engineering Council [4] .
El 15 de abril de 2009, Twitter ofreció a sus usuarios una solución que permite que sitios y servicios de terceros accedan a sus cuentas. Se llamaba "Iniciar sesión con Twitter" y se basaba en OAuth. Este evento desencadenó el primer estudio extenso de vulnerabilidad del protocolo y, unos días después, se descubrió una vulnerabilidad potencial que afectaba a todas las implementaciones de OAuth existentes. Después de eso, el 23 de abril, la comunidad de desarrolladores lanzó la primera adición de seguridad al protocolo, que se incluyó en la especificación OAuth Core 1.0 Revisión A actualizada, publicada el 24 de junio. En abril de 2010, se publicó el libro blanco RFC 5849 sobre el estándar OAuth [4] .
En 2010, se comenzó a trabajar en una nueva versión del protocolo OAuth 2.0 que no era compatible con versiones anteriores de OAuth 1.0 [1] . En octubre de 2012, se publicó el marco para OAuth 2.0 en RFC 6749 y el uso de token bearer en RFC 6750 .
Había varios requisitos previos para crear OAuth 2.0. En primer lugar, OAuth no es trivial de usar en el lado del cliente. Uno de los objetivos en el desarrollo del nuevo OAuth es facilitar el desarrollo de aplicaciones cliente. En segundo lugar, a pesar de la implementación de tres métodos (llamados flujos) declarados en el estándar para obtener un token (identificador único) para autorización: para aplicaciones web, clientes de escritorio y clientes móviles, de hecho, los tres métodos se fusionan en uno. Y, en tercer lugar, el protocolo resultó ser poco escalable. Además de nuevas transmisiones, se le agregaron [5] [6] :
Actualmente, OAuth 2.0 es utilizado por una gran cantidad de servicios, como Google , Instagram , Facebook , VKontakte y otros.
En julio de 2012, Eran Hammer, el actual editor del estándar OAuth 2.0, anunció su renuncia después de tres años de trabajar en el nuevo estándar y solicitó que se elimine su nombre de las especificaciones. Habló sobre sus puntos de vista en su sitio web [7] y luego dio una charla [8] . David Recordon también eliminó su nombre de la especificación sin dar razones [ 9 ] . Dick Hardt se convirtió en el editor del estándar OAuth2.0 y, a pesar de las opiniones de Eran Hammer, el marco OAuth 2.0 se publicó en RFC 6749 en octubre de 2012 [1] .
Cuando se utiliza la autorización OAuth , el usuario no transfiere su nombre de usuario y contraseña a los recursos protegidos directamente a la aplicación [3] . Es por eso:
En caso de autorización sin utilizar el protocolo OAuth, el usuario debe enviar su nombre de usuario y contraseña. Este método tiene desventajas adicionales [3] :
Aunque OAuth y OpenID tienen mucho en común, OAuth es un protocolo por derecho propio y no tiene nada que ver con OpenID [10] :
Conceptos básicos utilizados en los protocolos y ejemplos de su uso.
OAuth 1.0 define tres roles: cliente, servidor y propietario del recurso. Estos tres roles están presentes en cualquier operación de OAuth, en algunos casos el cliente también es el propietario del recurso. La versión original de la especificación utiliza un conjunto diferente de términos para estos roles: consumidor (cliente), servicio (servidor) y usuario (propietario del recurso) [11] . En el protocolo OAuth 2.0, había una separación de roles de servidor: un servidor de autorización y un servidor que almacena recursos protegidos se asignan por separado [6] .
OAuth admite 3 métodos de firma que se utilizan para firmar y validar solicitudes: PLAINTEXT , HMAC - SHA1 y RSA - SHA1 . PLAINTEXT es trivial de usar y toma mucho menos tiempo para calcular, pero solo puede ser seguro a través de HTTPS o canales seguros similares. HMAC : SHA1 ofrece un algoritmo simple y genérico que está disponible en la mayoría de las plataformas, pero no en todos los dispositivos heredados, y utiliza una clave compartida simétrica. RSA - SHA1 proporciona seguridad mejorada con un par de claves, pero es más complejo y requiere la generación de claves [12] .
Para evitar la amenaza de reutilización de solicitudes, OAuth utiliza un nonce y una marca de tiempo . El término "nonce" se usa para referirse a un código único, que es un conjunto aleatorio de letras y números y está diseñado para identificar de manera única una solicitud. Tener un identificador único en una solicitud le permite al proveedor de servicios evitar que se reutilice. Este enfoque se implementa generando una cadena única para cada solicitud enviada al servidor por el cliente. Para evitar la reutilización de solicitudes, el servidor DEBE almacenar los nonces recibidos [12] .
Sin embargo, almacenar todos los nonces recibidos puede resultar muy costoso para el servidor. Para evitar una sobrecarga de almacenamiento excesiva en OAuth, se agrega una marca de tiempo a cada solicitud, lo que permite que el servidor solo almacene el nonce durante un período de tiempo limitado especificado. Al recibir una solicitud con una etiqueta anterior a la permitida, el servidor la rechaza [12] .
OAuth 1.0 y OAuth 2.0 utilizan tres tipos de autoridad: credenciales de cliente ( clave de consumidor y secreto o credenciales de cliente ) , credenciales temporales ( token de solicitud y secreto o credenciales temporales ) y tokens ( token de acceso y secreto o credenciales de token en inglés ) [13] [ 3] .
Las credenciales del cliente se utilizan para autenticar al cliente. El servidor puede proporcionar servicios especiales a los clientes, como limitar el acceso gratuito o proporcionar al propietario del recurso información más detallada sobre los clientes que intentan acceder a los recursos protegidos. En algunos casos, las credenciales de los clientes no son seguras y solo se pueden usar con fines informativos, como en aplicaciones de escritorio.
El token se usa en lugar del nombre y la contraseña del propietario del recurso. El propietario del recurso no revela sus credenciales al cliente, pero permite que el servidor emita un token al cliente, una clase especial de credenciales que proporciona al cliente algunas capacidades limitadas. El cliente usa el token para acceder a un recurso protegido sin conocer la contraseña del propietario del recurso. El token consiste en una firma digital, generalmente (pero no siempre) un conjunto aleatorio de letras y números que es único y criptográficamente fuerte, y una clave para proteger el token del uso no autorizado. El token está limitado en términos de autoridad y duración y puede ser revocado en cualquier momento por el propietario del recurso, sin afectar los tokens emitidos a otros clientes [13] .
El proceso de autorización de OAuth también utiliza un conjunto de credenciales temporales que se utilizan durante la etapa de solicitud de autorización. Para atender a diferentes tipos de clientes (interfaz web, escritorio, móvil, etc.), los permisos temporales ofrecen flexibilidad y seguridad adicionales [13] .
Expliquemos cómo funciona el protocolo OAuth 1.0 usando un ejemplo [13] . Supongamos que un usuario (propietario del recurso) desea imprimir sus fotos (recursos) cargadas en photos.example.net (servidor) mediante el servicio de impresión "printer.example.net" (cliente).
El protocolo OAuth 2.0 no es compatible con el protocolo OAuth 1.0 [1] . En lugar de complementar OAuth 1.0, se tomó la decisión de desarrollar un protocolo diferente [10] . Por lo tanto, la forma en que funcionan OAuth 1.0 y OAuth 2.0 es diferente. Entonces, en el estándar OAuth 2.0 se describen los siguientes flujos (escenarios de interacción de las partes) [1] :
OAuth admite dos métodos para autenticar mensajes del cliente: HMAC - SHA1 y RSA - SHA1 . Es posible enviar mensajes sin firma, luego se indica " texto sin formato " en el campo de tipo de firma. Pero en este caso, según la especificación, la conexión entre el cliente y el servidor debe establecerse mediante el protocolo SSL o TLS [13] .
| Protocolos de autenticación e intercambio de claves | |
|---|---|
| Con algoritmos simétricos | |
| Con algoritmos simétricos y asimétricos | |
| Protocolos y servicios utilizados en Internet | |