El futuro de la autorización: por qué OAuth 2.0 es solo el comienzo

El futuro de la autorización: por qué OAuth 2.0 es solo el comienzo

La autorización es un componente crítico de la seguridad de las aplicaciones, ya que solo permite que los usuarios autenticados y autorizados accedan a los recursos protegidos. OAuth 2.0 se ha convertido en el protocolo de autorización estándar de la industria, proporcionando un marco para el control de acceso delegado.

Publicado por primera vez en 2012, OAuth 2.0 permite que las aplicaciones accedan a recursos alojados en un servidor de recursos en nombre del propietario del recurso, mediante la emisión de tokens de acceso. Permite a los usuarios otorgar acceso a aplicaciones de terceros a sus datos en otro servicio, sin exponer sus credenciales.

OAuth se ha adoptado ampliamente en la web, lo que permite la autorización para muchas plataformas importantes, incluidas Facebook, Google, Twitter y Microsoft. Sin embargo, a medida que el uso de OAuth ha crecido exponencialmente, también se han descubierto vulnerabilidades y debilidades. Estos han permitido a los atacantes robar tokens de acceso y hacerse pasar por usuarios válidos.

En este artículo, brindaremos una descripción general de cómo funciona OAuth 2.0, casos de uso comunes, mejores prácticas y vulnerabilidades. También miraremos más allá de OAuth hacia protocolos de autorización y autenticación más avanzados que tienen como objetivo mejorar la seguridad: OpenID Connect, TLS mutuo y WebAuthn. Al final, tendrá un conocimiento sólido de OAuth 2.0 y cómo utilizarlo de forma segura. Además, obtendrá información sobre nuevos estándares y técnicas que van más allá de OAuth para asegurar aún más el control de acceso para aplicaciones modernas.

Cómo funciona OAuth 2.0

OAuth 2.0 es un estándar abierto para la delegación de acceso que proporciona autorización segura para que las aplicaciones accedan a los recursos del servidor en nombre de un usuario. Permite a los usuarios otorgar acceso limitado a sus recursos sin exponer sus credenciales.

OAuth 2.0 define cuatro flujos de autorización principales:

Flujo del código de autorización

El flujo de código de autorización es más adecuado para clientes confidenciales, como aplicaciones web. Se trata de un código de autorización intermediario para intercambiar por un token de acceso:

  1. La aplicación cliente redirige al usuario al servidor de autorización para iniciar sesión y aprobar el acceso.
  2. El servidor de autorización autentica al usuario y lo redirecciona con un código de autorización.
  3. El cliente cambia el código de autorización por un token de acceso.
  4. El cliente puede utilizar el token de acceso para realizar llamadas API para acceder a los recursos.

Este flujo proporciona mayor seguridad porque el token de acceso nunca se transmite directamente a través del navegador del usuario.

Flujo implícitoEl flujo implícito está optimizado para clientes basados ​​en agentes de usuario, como aplicaciones web de una sola página. El token de acceso se devuelve directamente sin código de autorización:

  1. La aplicación cliente redirige al usuario al servidor de autorización para iniciar sesión y aprobar el acceso.
  2. El servidor de autorización autentica al usuario y lo redirecciona con un token de acceso en el fragmento de URL.
  3. El cliente puede utilizar el token de acceso para realizar llamadas API para acceder a los recursos.

Este flujo simplificado elimina la necesidad de viajes de ida y vuelta adicionales al servidor de autorización, pero es menos seguro porque el token de acceso está expuesto en el historial del navegador.

Comparación de flujos

El flujo del código de autorización es más seguro pero implica más viajes de ida y vuelta. El flujo implícito es más simple y está optimizado para clientes de agente de usuario a costa de la seguridad.

En general, OAuth 2.0 proporciona un marco de autorización delegado seguro para que las aplicaciones cliente accedan a los recursos del servidor de forma estandarizada. Sin embargo, aún existen vulnerabilidades si no se implementan adecuadamente.

Pros y contras de OAuth 2.0

Ventajas:

  • Autorización delegada sin compartir credenciales de usuario
  • Flujos de autorización flexibles para varios tipos de clientes.
  • Amplia adopción en las principales plataformas y proveedores

Desventajas:

  • La complejidad conduce a errores de implementación comunes
  • Se basa en HTTPS y el secreto de tokens por motivos de seguridad.
  • Los tokens de acceso pueden filtrarse si no se protegen adecuadamente
  • Contexto de usuario integrado limitado más allá de los alcances

OAuth 2.0 resuelve el problema clave de la autorización segura, pero tiene debilidades que los protocolos más avanzados intentan abordar.

Casos de uso de OAuth 2.0

OAuth 2.0 se utiliza habitualmente para habilitar flujos de autorización en una amplia variedad de aplicaciones y servicios en Internet. Algunos de los casos de uso y ejemplos más frecuentes incluyen:

  • Inicio de sesión en redes sociales: servicios como Facebook, Twitter, Google y GitHub aprovechan OAuth 2.0 para permitir a los usuarios “iniciar sesión con” sus credenciales de plataforma. Esto permite a los usuarios renunciar a crear nuevas cuentas y, en cambio, autorizar a estos sitios a conectarse a sus perfiles sociales existentes.

  • Autorización de aplicaciones: las aplicaciones móviles y de escritorio a menudo integran OAuth para autorizar el acceso a las API REST. Por ejemplo, una aplicación puede usar OAuth para obtener acceso a las fotos de un usuario en un servicio de almacenamiento en la nube, contactos en un servicio de libreta de direcciones u otros datos de un proveedor de API.- Seguridad e inicio de sesión único: OAuth permite la autenticación centralizada a través de un único proveedor de identidad, en lugar de administrar las credenciales para cada aplicación individualmente. Este enfoque de inicio de sesión único (SSO) es popular en entornos empresariales para mejorar la seguridad y la conveniencia.

  • Protección de cuentas de usuario: para los usuarios preocupados por la seguridad, OAuth permite autorizar el acceso a las aplicaciones sin tener que compartir sus credenciales principales. Esto protege la cuenta del usuario en caso de que una aplicación esté comprometida o sea maliciosa.

  • Integración de servicios: OAuth permite una integración perfecta entre diferentes plataformas a través de sus flujos de autorización y tokens de acceso. Los servicios pueden conectarse directamente entre sí a través de API en nombre de los usuarios, evitando fricciones y molestias al realizar pasos de autenticación redundantes.

En resumen, OAuth 2.0 proporciona un marco estandarizado para otorgar acceso limitado a los datos y capacidades del usuario sin exponer las credenciales. Sus flujos flexibles y su formato de token lo convierten en un protocolo ampliamente aplicable para la autorización en integraciones web, móviles, de escritorio, IoT y basadas en API. OAuth 2.0 es la base de gran parte de la perfecta interoperabilidad entre aplicaciones y servicios en la web moderna.

Mejores prácticas de OAuth 2.0

Para aprovechar al máximo los beneficios de seguridad de OAuth 2.0, es importante seguir las mejores prácticas en materia de registro, claves, tokens y tokens de actualización.

Registro y manejo de claves

  • Utilice HTTPS para los puntos finales de autorización y token. Esto protege contra ataques de intermediarios.

  • Generar claves criptográficamente fuertes con suficiente entropía. Los tamaños de clave recomendados son 2048 bits para RSA y 256 bits para EC.

  • Nunca codifique secretos de clientes en aplicaciones ni comparta secretos con partes que no sean de confianza. Almacene secretos de forma segura en el lado del servidor.

  • Establecer tiempos de caducidad cortos para los códigos de autorización, alrededor de 10 minutos. Esto reduce la ventana de interceptación.

  • Revocar los secretos de los clientes expuestos inmediatamente y generar nuevas claves.

Uso de tokens

  • Mantenga los tokens de acceso de corta duración, alrededor de 1 hora. Los tokens de actualización pueden tener una caducidad más larga, alrededor de 2 semanas.

  • Envíe tokens de acceso solo a través de HTTPS y solo a servidores confiables. Nunca incluya tokens en URL, registros o código de interfaz.

  • Valide siempre la audiencia del token para que coincida con la audiencia esperada para su API.

  • Verifique que el emisor coincida con el dominio de su servidor de autorización.

  • Verifique el algoritmo de firma del token y la clave con claves confiables conocidas.

Actualizar tokens- Emita tokens de actualización solo para aplicaciones y dispositivos propios y confiables. Evite proporcionar tokens de actualización para clientes de terceros.

  • Vincular tokens de actualización a una única combinación específica de ID de cliente e identidad de usuario.

  • Revocar tokens de actualización cuando el usuario cierra sesión o cambian los permisos. Emitir nuevos tokens al volver a autenticarse.

  • Tokens de actualización seguros equivalentes a una autorización a largo plazo. Transmita solo a través de HTTPS y restrinja el acceso mediante cifrado.

Seguir estas mejores prácticas garantizará que OAuth 2.0 proporcione una seguridad sólida para la autorización de API.

Vulnerabilidades de OAuth 2.0

Si bien OAuth 2.0 es una mejora con respecto a los protocolos de autenticación anteriores, todavía tiene vulnerabilidades que los atacantes pueden aprovechar si no se implementa y protege adecuadamente. Algunos ataques comunes de OAuth incluyen:

  • Secuestro de token: un atacante roba un token de acceso y lo utiliza para obtener acceso no autorizado a los recursos. Esto puede suceder si los tokens no están protegidos adecuadamente o no se transmiten a través de canales inseguros.

  • Interceptación del código de autorización: un atacante puede interceptar el código de autorización utilizado para intercambiar por un token de acceso durante el proceso de autorización, lo que le permite obtener un token de acceso válido.

  • Suplantación de cliente: un atacante se hace pasar por un cliente válido para engañar al servidor de autorización para que emita un token de acceso. La autenticación de cliente débil lo hace posible.

  • Suplantación de usuario: el atacante roba o adivina las credenciales de un usuario y las utiliza para autenticarse como usuario y obtener acceso a sus datos.

  • Flujos de OAuth rotos: la implementación incorrecta de los flujos y la validación de OAuth puede dejar los puntos finales abiertos a la explotación. Los atacantes pueden abusar de las fallas en la validación de redirección_uri, los parámetros de estado y la emisión de códigos/tokens para comprometer las cuentas.

  • Falsificación de solicitudes entre sitios (CSRF): los atacantes pueden obligar a los usuarios autenticados a realizar solicitudes en su nombre sin saberlo explotando la dependencia de OAuth en la redirección del navegador para los flujos.

  • Redirectores abiertos: permitir redireccionamientos abiertos después de iniciar sesión en OAuth puede permitir a los atacantes redirigir a los usuarios a sitios de phishing y robar credenciales o tokens.

Para evitar el abuso de OAuth, la implementación adecuada es crucial:

  • Utilice parámetros de estado y nonce para evitar CSRF
  • Hacer cumplir el registro y la validación seguros del cliente.
  • Utilizar canales de comunicación cifrados.
  • Establecer tiempos de vencimiento cortos para los tokens
  • Revocar tokens cuando ya no sean necesarios
  • Utilice tokens de actualización con moderación y cuidado
  • Siga las mejores prácticas de OAuth para validación y redirecciones.Si bien OAuth 2.0 ofrece un marco estandarizado para la autorización, las organizaciones deben tener cuidado de mitigar las vulnerabilidades mediante una implementación adecuada, controles de seguridad y políticas de acceso sólidas. Protocolos adicionales como OpenID Connect se basan en OAuth para mejorar la seguridad, lo que demuestra la necesidad de una evolución continua.

Más allá de OAuth 2.0

OAuth 2.0 ha sido un estándar importante para la autorización y todavía se utiliza ampliamente en la actualidad. Sin embargo, como estándar que tiene más de 10 años, OAuth 2.0 está empezando a mostrar su antigüedad y sus limitaciones frente a las amenazas de seguridad modernas. Estas son algunas de las razones clave por las que OAuth 2.0 puede que ya no sea suficiente:

  • Diseñado para escritorio y web, no para aplicaciones móviles o nativas - OAuth 2.0 se creó en la era anterior a las aplicaciones móviles y nativas. Se basa en redireccionamientos que no funcionan bien fuera del contexto de un navegador web. Esto puede crear vulnerabilidades de seguridad.

  • No cifrar tokens de forma predeterminada - Los tokens de OAuth 2.0 a menudo se envían sin cifrar, dejándolos abiertos a la interceptación. La especificación requiere https para el flujo de autorización, pero los tokens de acceso aún se pueden transmitir sin cifrar.

  • No hay métodos integrados para validar la identidad - OAuth 2.0 se centra en la autorización y la delegación de acceso. No verifica la identidad del usuario. Esto deja espacio para ataques de suplantación de identidad.

  • Riesgos de incrustación y reutilización de tokens: OAuth 2.0 proporciona autorización de un solo uso, pero no impide que el token se use varias veces. Los tokens con acceso más amplio también pueden integrarse en aplicaciones, ampliando la exposición.

  • No se requiere prueba de posesión - No existe prueba criptográfica de que la parte que utiliza un token sea el usuario autorizado previsto. Esto crea un mayor riesgo si se intercepta un token.

  • Estándares de cifrado limitados - OAuth 2.0 solo admite cifrados más antiguos como SHA-1. Los algoritmos modernos más potentes como SHA-256 no están integrados en la especificación principal.

A medida que las amenazas han evolucionado, las capacidades de OAuth 2.0 para protegerse contra ellas están llegando a sus límites. Si bien todavía se usa ampliamente, OAuth 2.0 debe ampliarse y reemplazarse por estándares de autorización más sólidos y modernos para ciertos casos de uso. Explorar protocolos como OpenID Connect, TLS mutuo y WebAuthn ofrece opciones para una mayor seguridad en el futuro.

Conexión OpenIDOpenID Connect es un protocolo de autenticación creado sobre OAuth 2.0 que proporciona capacidades de identidad adicionales. Con OAuth 2.0, el servidor de recursos recibe un token de acceso que otorga acceso, pero no proporciona ninguna información sobre la identidad del usuario.

OpenID Connect permite a los clientes verificar la identidad del usuario mediante autenticación con un servidor de autorización. Esto permite al cliente obtener información básica del perfil del usuario. OpenID Connect utiliza JWT (JSON Web Tokens) que contienen afirmaciones sobre la autenticación del usuario, que pueden transmitirse al cliente.

Algunos casos de uso clave en los que OpenID Connect mejora la seguridad:

  • Inicio de sesión único (SSO): OpenID Connect permite un inicio de sesión único simple en múltiples sitios y aplicaciones. La autenticación la maneja el servidor de autorización del proveedor de identidad, por lo que no es necesario que cada sitio maneje su propia autenticación.

  • Mayor integridad: el token de identificación contiene afirmaciones firmadas que han sido verificadas de forma segura por el proveedor de identidad. Esto proporciona mejores garantías de integridad que los tokens de acceso OAuth estándar.

  • Acceso al perfil de usuario: OpenID Connect proporciona opcionalmente acceso a la información del perfil del usuario final, brindando al cliente contexto adicional sobre quién es el usuario sin necesidad de llamadas API adicionales.

  • Mayor confianza en la identidad: los estándares en torno al uso del alcance, las afirmaciones de JWT y el cifrado brindan una mayor confianza en que el usuario es quien afirma en comparación con OAuth básico.

En resumen, OpenID Connect se basa en la autorización proporcionada por OAuth 2.0 para proporcionar también una autenticación confiable y verificar la identidad del usuario. Para casos de uso como SSO y cuando la garantía de identidad es fundamental, OpenID Connect es un protocolo más seguro y sólido.

TLS mutuo para una autenticación más sólida

Mutual TLS proporciona una autenticación más sólida que el TLS tradicional al requerir autenticación bidireccional entre el cliente y el servidor. Con mTLS, tanto el cliente como el servidor deben proporcionar certificados para identificarse antes de establecer una conexión TLS cifrada.

Así es como funciona la autenticación mTLS:

  • El cliente inicia el protocolo de enlace enviando al servidor su certificado de cliente. Este certificado lo emite una autoridad certificadora (CA) confiable y verifica la identidad del cliente.

  • Luego, el servidor proporciona su propio certificado de servidor al cliente. Este certificado se valida con la CA confiable para autenticar la identidad del servidor.- El cliente y el servidor negocian una sesión TLS cifrada si ambas partes validan exitosamente los certificados de cada uno. Esto crea un canal de comunicación bidireccional autenticado.

  • El cliente y el servidor ahora pueden intercambiar datos de forma segura a través del túnel TLS cifrado sabiendo que se han verificado las identidades en ambos extremos.

mTLS es más seguro que el TLS estándar que solo autentica el servidor ante el cliente. Al requerir autenticación mutua, mTLS evita conexiones de red no autorizadas, frustrando ataques de intermediarios.

Casos de uso en los que mTLS mejora la seguridad:

  • Asegurar las comunicaciones entre microservicios. mTLS evita que microservicios no autorizados se unan a la malla.

  • Autenticación para pods de Kubernetes que se conectan internamente. mTLS verifica las identidades de los pods que se comunican dentro del clúster.

  • Asegurar la comunicación del dispositivo IoT. mTLS bloquea la comunicación de máquina a máquina al requerir certificados de cliente.

  • Transacciones bancarias y financieras. mTLS garantiza la integridad de las transacciones entre sistemas financieros.

La implementación requiere soporte mTLS tanto del cliente como del servidor. Los balanceadores de carga como NGINX pueden terminar conexiones mTLS y luego retransmitir el tráfico en modo TLS simple. Los SDK de cliente facilitan la integración de la autenticación mTLS en aplicaciones móviles y web que se conectan a servicios backend. Con bibliotecas y equilibrio de carga adecuados, las empresas pueden implementar seguridad mTLS a escala.

WebAuthn/FIDO2

WebAuthn (autenticación web) y FIDO2 son estándares web emergentes que brindan una alternativa a la autenticación tradicional basada en contraseñas.

WebAuthn permite a los sitios web registrar y autenticar usuarios utilizando criptografía de clave pública en lugar de contraseñas. Esto se habilita a través de autenticadores como claves de seguridad o datos biométricos. El estándar fue creado por la Alianza FIDO y el Consorcio World Wide Web (W3C).

FIDO2 es un conjunto de especificaciones técnicas que permiten métodos de autenticación sin contraseña utilizando credenciales seguras como claves de seguridad, datos biométricos o autenticadores de plataforma. Es una extensión del estándar FIDO (Fast Identity Online).

Estos son algunos de los beneficios clave de WebAuthn y FIDO2 sobre la autenticación de contraseña tradicional:

  • Mayor seguridad - Las contraseñas pueden ser débiles, reutilizarse, filtrarse, robarse o estar sujetas a ataques de phishing. WebAuthn utiliza criptografía asimétrica (clave pública) para ofrecer una forma de autenticación mucho más sólida y resistente a estas amenazas.- Mejor experiencia de usuario - No es necesario crear ni recordar contraseñas. Los usuarios simplemente se autentican con una huella digital o una clave de seguridad, lo cual es más rápido y sencillo.

  • Costos reducidos: las organizaciones gastan menos en restablecimientos de contraseñas, llamadas al servicio de asistencia técnica y otros problemas relacionados con contraseñas que añaden gastos generales de TI.

  • Protección de la privacidad - Con WebAuthn, las credenciales originales (plantillas biométricas o claves privadas) nunca salen del dispositivo del usuario. Esto protege la privacidad.

  • Independiente de la plataforma/dispositivo: WebAuthn funciona en dispositivos móviles y de escritorio. Y no bloquea a los usuarios en una plataforma o dispositivo en particular.

En general, WebAuthn y FIDO2 representan un importante paso adelante para la seguridad y usabilidad de la autenticación en la web. A medida que estos estándares obtengan una adopción más amplia, veremos menos dependencia de sistemas vulnerables basados ​​en contraseñas.

Conclusión

OAuth 2.0 se ha convertido en el estándar de autorización y autenticación para muchas aplicaciones, proporcionando a los usuarios una forma de otorgar acceso limitado a sus datos sin exponer sus credenciales. Sin embargo, como protocolo más antiguo, OAuth 2.0 tiene algunas limitaciones en cuanto a seguridad, alcance de acceso y experiencia del usuario.

Los protocolos más nuevos tienen como objetivo mejorar OAuth 2.0 de varias maneras:

  • OpenID Connect se basa en OAuth 2.0 para agregar servicios de identidad, proporcionando verificación de identidad junto con autenticación y autorización. Esto ayuda a abordar algunas de las vulnerabilidades de seguridad en OAuth 2.0.

  • Mutual TLS proporciona autenticación basada en certificados tanto del cliente como del servidor, lo que evita ataques de intermediario. Si bien es más complejo de implementar, TLS mutuo mejora la integridad y la protección de la privacidad en comparación con OAuth 2.0 solo.

  • WebAuthn/FIDO2 utiliza criptografía de clave pública en lugar de contraseñas para la autenticación, lo que proporciona un inicio de sesión resistente al phishing y a la manipulación. Este protocolo podría reemplazar completamente a OAuth para iniciar sesión en muchos casos.

En general, si bien OAuth 2.0 sentó las bases para una autorización segura, su antigüedad se refleja en varias limitaciones heredadas. Los protocolos más nuevos se basan en OAuth, pero abordan sus debilidades en materia de seguridad, privacidad y experiencia del usuario.

Para aplicaciones altamente confidenciales como atención médica, servicios financieros y gestión de identidades, se debe considerar seriamente el TLS mutuo y protocolos como WebAuthn para brindar una defensa en profundidad. Incluso para las aplicaciones de consumo, aumentar OAuth con OpenID Connect ayuda a garantizar una mejor integridad de la identidad y autenticación del usuario.Esté atento a APIRobots para obtener más información y actualizaciones sobre este apasionante campo. No pierda las oportunidades que las API pueden brindar a su negocio. Contáctenos hoy en API Robots una Agencia de desarrollo de API y liberemos todo el potencial de las API juntos.