OAUTH 2.0 es un mecanismo de autorización -no de autenticación-, que detalla cómo gestionar un acceso delegado a diferentes aplicaciones (web, nativas o móviles), y dispositivos conectados. Se ha convertido en el estándar de facto de la industria para conceder acceso a un conjunto de recursos, por ejemplo, API remotas o datos de usuario y para ello utiliza tokens de acceso.
Esto es lo que tienes que saber sobre él.
Índice de temas
OAUTH 2.0: orígenes
OAUTH 2.0 hace referencia a las siglas Open Authorization o autorización abierta. Se trata de un estándar diseñado para permitir que un sitio web o una aplicación accedan a recursos alojados por otras aplicaciones web en nombre de un usuario.
OAUTH 2.0 es ahora el estándar de facto de la industria para la autorización en línea
Este protocolo fue desarrollado en 2006 por la Internet Engineering Task Force (IETF) como un estándar abierto para la autorización y surgió para paliar la necesidad que se establece del envío continua de credenciales entre cliente y servidor.
Esta versión sustituyó a OAUTH 1.0 en 2012 y ahora es el estándar de facto de la industria para la autorización en línea. En concreto, este protocolo proporciona acceso consentido y restringe las acciones que la aplicación del cliente puede realizar en los recursos en nombre del usuario, sin compartir nunca las credenciales del usuario.
En otras palabras, OAUTH 2 es un framework de autorización que permite a las aplicaciones obtener acceso (limitado) a las cuentas de usuario de determinados servicios, como Facebook, GitHub, Twitter, Steam, BitBucket, LinkedIn y muchos más. Consiste en delegar la autenticación de usuario al servicio que gestiona las cuentas, de modo que sea éste quien otorgue el acceso para las aplicaciones de terceros. Es decir, el usuario delega la capacidad de realizar ciertas acciones, no todas, a las cuales da su consentimiento para hacerlas en su nombre.
Roles de OAUTH 2.0
Los roles definen los componentes esenciales de un sistema de OAUTH 2.0 y son:
Dueño del recurso: El usuario o sistema que posee los recursos protegidos y puede conceder acceso a ellos. La API no es suya, pero los datos que maneja sí lo son. Da autorización a una determinada aplicación para acceder a su cuenta y poder hacer algunas cosas en su nombre. El conjunto de cosas que puede hacer la aplicación en su nombre se llama alcance como, por ejemplo, acceso de lectura.
Cliente: El cliente es el sistema que requiere acceso a los recursos protegidos. Es la aplicación que desea acceder a esa cuenta de usuario (una aplicación web, un dispositivo IoT, etc). Para acceder a los recursos, el cliente debe poseer el token de acceso correspondiente.
Servidor de autorización: Este servidor recibe las solicitudes de tokens de acceso del cliente y las emite una vez que el propietario del recurso se ha autenticado y ha dado su consentimiento. El servidor de autorización expone dos puntos de conexión: el punto de conexión de autorización, que maneja la autenticación interactiva y el consentimiento del usuario, y el punto de conexión de token, que está involucrado en una interacción de máquina a máquina.
Servidor de recursos protegidos: Un servidor que protege los recursos del usuario y recibe las solicitudes de acceso del cliente. Acepta y valida un token de acceso del cliente y le devuelve los recursos adecuados. Es la API propiamente.
¿Cómo funciona el OAUTH?
Teniendo en cuenta estos roles podemos aclarar cómo funciona este estándar. Así, en el nivel más básico, antes de poder utilizar OAUTH 2.0, el cliente debe adquirir sus propias credenciales, un id de cliente y un client secret, del servidor de autorización para identificarse y autenticarse al solicitar un token de acceso.
Con este protocolo, las solicitudes de acceso son iniciadas por el cliente, por ejemplo, una aplicación móvil, un sitio web, una aplicación de televisión inteligente, una aplicación de escritorio, etc.
La solicitud, el intercambio y la respuesta de los tokens siguen el siguiente flujo general:
1.El cliente solicita autorización (solicitud de autorización) al servidor de autorización, proporcionando el id y el client secret como identificación; también proporciona los ámbitos y un URI de extremo (URI de redireccionamiento) al que enviar el token de acceso o el código de autorización.
2.El servidor de autorización autentica al cliente y verifica que los ámbitos solicitados están permitidos.
3.El propietario del recurso interactúa con el servidor de autorización para conceder el acceso.
4.El servidor de autorización redirige de vuelta al cliente con un código de autorización o un token de acceso, según el tipo de concesión, como se explicará en la siguiente sección. También puede devolverse un token de actualización.
5.Con el token de acceso, el cliente solicita acceso al recurso desde el servidor de recursos.
Funcionamiento para móviles u otros dispositivos
Aunque la web es la principal plataforma para OAUTH 2.0, esta especificación también describe cómo gestionar este modo de acceso delegado a otros tipos de clientes (aplicaciones basadas en el navegador, aplicaciones web del lado del servidor, aplicaciones nativas/móviles, dispositivos conectados, etc.).
Tokens: definición y gestión
Hay que aclarar que OAUTH 2.0 es un protocolo de autorización y no un protocolo de autenticación. Es por ello que está diseñado principalmente como un medio para conceder acceso a un conjunto de recursos, por ejemplo, API remotas o datos de usuario.
OAUTH 2.0 es un protocolo de autorización y no un protocolo de autenticación
Este estándar utiliza tokens de acceso. ¿Y qué es un token de acceso? Pues es un dato que representa la autorización para acceder a los recursos en nombre del usuario final. OAUTH 2.0 no define un formato específico para los tokens de acceso. Sin embargo, en algunos contextos, se suele utilizar el formato JSON Web Token (JWT). Esto permite a los emisores de tokens incluir datos en el propio token. Además, por razones de seguridad, los tokens de acceso pueden tener una fecha de caducidad.
Ejemplos de OAUTH 2.0
OAUTH 2.0 se ha convertido en uno de los estándares más utilizados a la hora de compartir recursos a través de API. Empresas como Google, Twitter, Facebook y Microsoft han encontrado en este protocolo un funcionamiento adecuado para poder realizar alianzas con otras compañías sin la preocupación de ceder información que no quieren compartir.
OAUTH 1.0 vs OAUTH 2.0
El protocolo OAUTH ha evolucionado con el tiempo. De hecho, la versión 2.0 ha sustituido a la OAUTH 1.0 porque esta última se ha quedado obsoleta al no considerarse segura. Debido a esto, la mayoría de los proveedores de servicios sólo permiten el acceso con OAUTH 2.0.
En comparación, OAUTH 1.0 es más fácil de usar y presenta un flujo de trabajo más sencillo en algunos aspectos. Pero, como hemos dicho antes, ya no se considera una forma segura de trabajar con cuentas de usuario. Algo que solventa la versión más moderna al añadir dos pasos al flujo de trabajo de autorización.
En concreto, la 2.0 es compatible con HTTPS y secretos firmados, por lo que no resulta necesario cifrar los tokens en los puntos de contacto (dispositivos de usuario). HTTPS cifra los tokens de acceso en tránsito, aunque algunos servicios que almacenan información de identificación personal (PII) u otros datos delicados siguen cifrando los datos en reposo.
Sin embargo, hay un aspecto negativo de OAUTH 2.0 y es que permite la transferencia de datos a través de canales no cifrados, por lo que los desarrolladores son responsables de mantener el cifrado TLS/SSL a través de los canales.
OAUTH vs otras tecnologías, como OpenID o SAML
Pero ¿qué aporta de diferenciador OAUTH respecto a otras tecnologías como OpenID o SMAL? En general, cuando los consumidores utilizan OAUTH, el proveedor de servicios proporciona acceso autorizado a los datos de un usuario solamente después de que dé su consentimiento. En otras palabras, es una manera de compartir datos utilizando un token de autorización proporcionado por el consumidor después de que el usuario verifique sus credenciales.
OpenID es distinto, aunque ambos se utilizan juntos. El inicio de sesión único (SSO) es una estrategia de seguridad común que utiliza un proveedor para autenticar a los usuarios en varios servicios. OpenID es uno de los protocolos SSO más antiguos, introducido en 2005 para autenticar en LiveJournal. Ha pasado por algunas actualizaciones, pero se consideró demasiado difícil de implementar en comparación con otros métodos de la época, principalmente Facebook Connect. Como Facebook era una marca muy conocida, la mayoría de los desarrolladores se pasaron a Facebook Connect para que los usuarios se sintieran más cómodos autenticándose en sus aplicaciones.
En 2014, OpenID rediseñó su código y posteriormente se incorporó a OAUTH. Ahora, OAUTH utiliza OpenID como capa de autenticación y OAUTH se ocupa de la capa de autorización. El proceso es fluido para el usuario, pero los consumidores pueden integrar más fácilmente OAUTH tanto para autenticar a los usuarios como para obtener acceso a los datos de sus cuentas.
¿Y si hablamos de SAML? Estas siglas proceden del inglés Security Assertion Markup Language, que podría traducirse como Lenguaje de Marcado para Confirmaciones de Seguridad.
La principal diferencia con OAUTH es que SAML realiza tanto la autenticación como la autorización. OAUTH utiliza OpenID como capa de autenticación, pero no gestiona la autenticación por sí mismo. Las aplicaciones que utilizan SAML no necesitan ningún otro servicio para proporcionar autenticación.
Otra diferencia entre los dos protocolos es el lenguaje utilizado para trasladar datos entre servicios. SAML utiliza XML; OAUTH utiliza JSON, el formato preferido para las transferencias de datos. La mayoría de los servicios de datos trabajan principalmente con JSON, lo que hace que OAUTH sea más fácil de integrar para la mayoría de las empresas.
¿Qué es OAUTH 2 JWT?
La diferencia entre OAUTH 2.0 y JWT es que, OAUTH es un framework que autoriza accesos a recursos de diversas aplicaciones por medio de un token, mientras que JWT es un protocolo de autenticación que genera, envía y valida el token de acceso.
Cumplen, pues, objetivos diferentes en el proceso de seguridad y protección de datos.
Tipos de concesiones
Cuando hablamos de OAUTH 2.0 es fundamental especificar qué son las concesiones. Estas son, ni más ni menos, que el conjunto de pasos que un cliente tiene que realizar para obtener la autorización de acceso a los recursos.
El marco de autorización proporciona varios tipos de concesión para hacer frente a diferentes escenarios:
Concesión del código de autorización: El servidor de autorización devuelve al cliente un código de autorización de un solo uso, que se intercambia por un token de acceso. Esta es la mejor opción para las aplicaciones web tradicionales en las que el intercambio puede realizarse de forma segura en el lado del servidor. El flujo del código de autorización puede ser utilizado por aplicaciones de página única (Single Page Apps, SPA) y aplicaciones móviles/nativas. Sin embargo, en este caso, el client secret no se puede almacenar de forma segura, por lo que la autenticación durante el intercambio se limita al uso del id del cliente únicamente.
Concesión implícita: Un flujo simplificado en el que el token de acceso se devuelve directamente al cliente. El servidor de autorización puede devolver el token de acceso como un parámetro en el URI de devolución de llamada o como una respuesta a la publicación de un formulario. La primera opción está ahora obsoleta debido a la posible fuga de tokens.
Concesión del código de autorización con clave de prueba para el intercambio de códigos (PKCE): Este flujo de autorización es similar a la concesión del código de autorización, pero con pasos adicionales que lo hacen más seguro para las aplicaciones móviles/nativas y SPA.
Tipo de concesión de credenciales del propietario del recurso: Requiere que el cliente adquiera primero las credenciales del propietario del recurso, que se pasan al servidor de autorización. Por lo tanto, se limita a los clientes de total confianza. Tiene la ventaja de que no implica ninguna redirección al servidor de autorización, por lo que es aplicable en los casos de uso en los que una redirección es inviable.
Tipo de concesión de credenciales de clientes: Se utiliza para aplicaciones no interactivas, por ejemplo, procesos automatizados, microservicios, etc. En este caso, la aplicación se autentica por sí misma mediante el uso de su id de cliente y su client secret.
Flujo de autorización de dispositivos: Una concesión que permite el uso de aplicaciones en dispositivos con restricciones de entrada, como las televisiones inteligentes.
Concesión del token de actualización: El flujo que implica el intercambio de un token de actualización por un nuevo token de acceso.
Tipos de clientes
Respecto a los tipos de clientes podríamos determinar que existen dos:
- Clientes confidenciales: son aquellos que son capaces de guardar una contraseña sin que sea expuesta. Una aplicación nativa compilada es un buen ejemplo de este tipo de clientes.
- Clientes públicos: son aquellos que no son capaces de mantener esta contraseña a salvo, como por ejemplo aplicaciones JavaScript, Angular, etcétera.
En función del tipo de cliente, se implementa un flujo de OAUTH 2.0 de diferentes formas.
¿Por qué utilizar OAUTH 2.0?
OAUTH 2.0 permite a los usuarios compartir datos de forma segura manteniendo la privacidad de sus nombres de usuario, contraseñas y otra información. A la vez que proporciona flujos de autorización seguros para aplicaciones web y de escritorio, así como para dispositivos móviles.
OAUTH 2.0 se usa mucho más de lo que creemos. Pongamos un ejemplo. Un usuario tiene una cuenta en Facebook o Twitter, y quiere acceder a otra plataforma, pero sin tener que registrarse. En este caso esa aplicación puede pedir al usuario que se autentique en Facebook o Twitter, y si considera que la información a la que le da acceso es correcta, le podría permitir realizar un conjunto cerrado de acciones dentro de su plataforma.
Gracias a este protocolo, esa plataforma de terceros no tendría por qué tener ese nombre de usuario ni la contraseña almacenados, sobre todo siendo un nombre de usuario y contraseña de otro servicio distinto, como podría ser alguna de estas redes sociales.
Ventajas de OAUTH
- Estándar de seguridad muy utilizado para las autorizaciones de acceso a los datos de los usuarios. Protege aplicaciones web y móviles, lo que permite compartir la información confidencial con otras aplicaciones, sin la necesidad de tener que revelar las credenciales de los usuarios.
- Simplifica los procesos de inicio de sesión a las empresas, mejorando a su vez la seguridad de los datos. Si los usuarios quieren acceder a aplicaciones en línea, pueden utilizar credenciales de otros servicios en internet, por ejemplo. Esto evita la necesidad de crear nuevas cuentas, con nuevos usuarios y contraseñas.
OAUTH 2,0 destaca por ser una solución segura, flexible y muy sencilla de utilizar
- Integración con servicios externos más sencilla como calendarios, correo electrónico u otras herramientas de productividad.
- Control de todos los permisos de las aplicaciones de terceros.
- Más protección y privacidad de todos los usuarios. Cada individuo puede generar una revocación de acceso para cesar el servicio en cualquier momento.
Vulnerabilidades
Aunque es más seguro que compartir credenciales, OAUTH no está exento de riesgos.
Phishing
Los atacantes suelen utilizar enlaces a páginas web con solicitudes para que los usuarios introduzcan credenciales para autenticarse en sus cuentas. La página parece una página oficial similar a un servicio que utiliza OAUTH. Pero en lugar de autenticarse en un servicio oficial, el usuario está introduciendo sus credenciales en una página web de phishing de un atacante.
Permisos demasiado amplios
Cuando los usuarios instalan y autorizan aplicaciones a través de OAUTH, a menudo hacen clic en aceptar sin revisar detenidamente el alcance de los permisos. Cualquier app que tenga permisos de acceso amplios es un riesgo potencial para la seguridad de su organización.
Las aplicaciones externas pueden ser explotadas fácilmente. Los atacantes pueden utilizar el acceso OAUTH para comprometer y secuestrar cuentas en la nube. Hasta que se revoque explícitamente el token OAUTH, el atacante tiene acceso persistente a la cuenta y los datos del usuario, incluso si éste cambia la contraseña de la cuenta en la nube o utiliza la autenticación de dos factores (2FA).
Aplicaciones OAUTH malintencionadas
Algunas aplicaciones y sus solicitudes de permiso OAUTH son abiertamente malintencionadas.
Secuestro de cuentas en redes sociales
Con OAUTH 2.0 las aplicaciones pueden autenticar a los usuarios, pero entraña un problema y es que más del 41% de las aplicaciones que utilizan este estándar no validan los datos del usuario. Esto hace posible secuestrar las cuentas de redes sociales, por ejemplo.
Las posibles consecuencias de este exploit (programa informático que se aprovecha de un error para provocar un comportamiento no intencionado o imprevisto en un software, hardware o en cualquier dispositivo electrónico) son enormes. Muchas de las aplicaciones involucradas almacenan datos sensibles a la privacidad en la nube. Si un atacante inicia sesión como si fueras tú con una aplicación comprometida, todos sus datos estarán ahí.
