• Tiempo de lectura: 4 min.
Pocket Facebook Twitter WhatsApp Correo electrónico
Las plataformas comerciales permiten a varios actores cerrar acuerdos, iniciar procesos operativos y mediar en los servicios comerciales entre los participantes. Pero se recomienda precaución al configurar tales plataformas: no solo en el contexto del GDPR, la seguridad y la economía de datos deben tenerse en cuenta como aspectos centrales en la arquitectura de la plataforma. ¿Qué tecnologías son adecuadas para federalizar los datos de inicio de sesión y la información de perfil sin recopilar perfiles de usuario críticos para la seguridad?
OAuth (autorización abierta)
Primero, echemos un vistazo a OAuth. En el mundo moderno de las redes sociales, cada uno de nosotros usa docenas de aplicaciones y sitios web todos los días. Para no tener que crear constantemente un nuevo perfil para cada proveedor individual, el protocolo de autorización OAuth se ha desarrollado desde 2012 por iniciativa de Facebook y Twitter. Describe cómo los servicios previamente conocidos pueden acceder de forma segura a sus recursos en nombre de sus usuarios sin compartir la información de inicio de sesión específica. De esta forma, una cuenta que ya ha sido creada (por ejemplo en Facebook o Google) se puede utilizar para iniciar sesión en otros servicios sin revelar su contraseña o dirección de correo electrónico. En términos generales, OAuth funciona de la siguiente manera.
Supongamos que Melanie quiere registrarse en Aliexpress y selecciona "Registrarse con Google" como una de las opciones que se ofrecen:
Aliexpress crea una URL para el servicio de registro de Google, que contiene las áreas de perfil deseadas (ámbitos) requeridas por el perfil de Melanie, y reenvía el navegador de Melanie a esta URL.
Google reconoce que la solicitud proviene de Aliexpress y le informa a Melanie qué información y servicios de Google podrá utilizar Aliexpress si está de acuerdo.
Melanie le da permiso a Google para liberar los datos de los ámbitos deseados a Aliexpress.
La API de Google envía un token de concesión por única vez a Aliexpress, al que el servicio responde con un secreto negociado entre él y Google para identificar de manera única a Aliexpress.
Google responde con un token de acceso que representa la autenticación y las aprobaciones de Melanie.
Aliexpress transmite los tokens de acceso de Melanie a una de las API de Google autorizadas para cada solicitud.
La API de Google verifica la validez del token y entrega los datos solicitados a Aliexpress.
El protocolo OAuth allanó el camino para los protocolos de autorización y de inicio de sesión federalizados. Sin embargo, adolece de la fuerte correlabilidad de los metadatos: Google aprende mucho sobre la relación de información entre Aliexpress y Melanie. Además, el método depende en gran medida de la disponibilidad y la buena voluntad por parte de Google y requiere que los clientes puedan guardar tokens y secretos específicos del servicio para sí mismos y familiarizarse activamente entre sí antes de usar el método.
Token web JSON (JWT)
Desde hace algunos años, JSON Web Token (JWT) ha sido una especificación basada en JSON para tokens de seguridad, cuya integridad se garantiza mediante firmas criptográficas. JWT contiene toda la información de autenticación y autorización de una entidad que es relevante para un caso de uso. Esto elimina la necesidad de consultar bases de datos para determinar autorizaciones o para guardar datos de sesión en el servidor ("sesión sin estado").
No te pierdas nada: ¡Suscríbete al boletín t3n! 💌
Por favor, introduce una dirección de correo electrónico válida.
Desafortunadamente, hubo un problema al enviar el formulario. Inténtalo de nuevo.
Por favor, introduce una dirección de correo electrónico válida.
Nota sobre el boletín y la protección de datos
¡Casi terminado!
Haga clic en el enlace del correo electrónico de confirmación para completar su registro.
¿Quieres más información sobre la newsletter? Descubra más ahora
Como resultado, los tokens web JSON se han vuelto particularmente populares para la autenticación en entornos de sistemas distribuidos. Después de una identificación exitosa, un servidor de autenticación emite al usuario un JWT con información de autorización y, si es necesario, características personales y lo firma con un par de claves, cuya clave pública puede dar a conocer a otros servidores de aplicaciones. Tan pronto como alguien les presenta un JWT como función de autenticación, los servidores de aplicaciones pueden verificar la firma para asegurarse de que la información del token realmente provenga de un servidor de autenticación en el que confían.
JWT son ideales para la autenticación de usuarios en entornos de microservicios. A diferencia de las arquitecturas backend monolíticas, no pueden compartir un estado de sesión. Para autenticar una solicitud y poder probar sus autorizaciones, todo lo que necesita es conocimiento de un certificado de acceso público con el que se pueda verificar la firma del JWT. Los servicios de registro también pueden utilizar esto para proporcionar autorizaciones para sistemas de terceros.
Dado que los JWT son en sí mismos características de autenticación suficientes, su seguridad depende principalmente de que sus usuarios los mantengan en secreto y no sean interceptados en tránsito. Por lo tanto, generalmente solo se proporcionan fechas de vencimiento a muy corto plazo y sus usuarios deben renovarlos regularmente con la ayuda de tokens de actualización que se utilizan exclusivamente para esta aplicación.
También interesante: Hola Token, adiós contraseña! GitHub está configurado para ser más seguro en 2021
El futuro: identidades soberanas
Si bien OAuth y JWT representan el estándar actual para la seguridad de la plataforma, aún sufren el hecho de que se basan en un proceso de autenticación centralizado y una confianza federalizada. En el futuro, por lo tanto, serán reemplazados por las denominadas identidades auto-soberanas (SSI). En general, SSI significa que las personas administran su identidad digital de forma completamente independiente (por ejemplo, en forma de billetera en un dispositivo móvil) y ya no dependen de un proveedor de servicios de identidad central. En lugar de intercambiar combinaciones de correo electrónico / contraseña, la autenticación se realiza mediante la verificación de un denominado identificador descentralizado (DID) mediante firmas digitales. Dependiendo de la aplicación, un usuario puede utilizar varios DID para diferentes aspectos de su identidad digital. DID esencialmente representa una colección de claves que se pueden resolver en sistemas de acceso público. Por lo general, no se guardan en un silo de información como un servicio de autenticación de Google federado, sino que se resuelven a la versión actualmente válida con la ayuda de sistemas descentralizados y sin confianza como blockchains. Las autorizaciones se emiten utilizando las denominadas credenciales verificables a través de DID. A su vez, pueden presentarse como JWT. Su legitimidad puede ser verificada por un sistema de terceros utilizando las claves públicas almacenadas en un documento DID por el emisor y el sujeto de autenticación.
Conclusión
La búsqueda de formas y tecnologías para intercambiar información de los usuarios de forma segura y sencilla en las plataformas está lejos de terminar. Si bien los procedimientos de administración de derechos y autenticación federalizados comunes tienen consecuencias problemáticas para la seguridad, la correlabilidad y la protección de datos, las identidades controladas de forma autónoma enfrentan a sus usuarios con la responsabilidad de tener que guardar sus secretos ellos mismos. Los servicios de confianza descentralizados del mundo de las tecnologías de contabilidad distribuida resuelven el anclaje y la seguridad de los identificadores públicos, pero plantean nuevas preguntas sobre la trazabilidad y la usabilidad y son difíciles de inducir a interoperar entre sí. El objetivo de registrarse en cualquier sistema con una tarjeta de identificación autoemitida y certificada por el estado sin publicar todo el historial de registro aún está por delante. Sin embargo, para entonces, a más tardar, los servidores de registro y creación de perfiles profanos de los pulpos de datos federalizados podrían desconectarse para siempre.
Stefan Adolf
Stefan Adolf es desarrollador embajador en Turbine Kreuzberg. Su tarea principal es comunicarse con la comunidad de desarrolladores. También actúa como líder tecnológico en proyectos de riesgo y como "líder intelectual" tecnológico en Turbine Kreuzberg.
Puede que también te interese eso
Pocket Facebook Twitter WhatsApp Correo electrónico
Stefan Adolf
Stefan Adolf es desarrollador embajador en Turbine Kreuzberg. Su...
Temas relacionados
API de seguridad cibernética Protección de datos del navegador Facebook
No te pierdas nada: nuestra newsletter
Por favor, introduce una dirección de correo electrónico válida.
Elija su boletín t3n
+ Seleccionar otros
Seleccione al menos un boletín.
Desafortunadamente, hubo un problema al enviar el formulario. Inténtalo de nuevo.
Nota sobre el boletín y la protección de datos
¡Casi terminado!
Haga clic en el enlace del correo electrónico de confirmación para completar su registro.
