Bytes & Chips

La autenticación de usuarios es uno de los elementos claves de toda aplicación; ya no solo por aspectos de seguridad, también por lo fundamental que es a la hora de poder diferenciar y mejorar la experiencia de usuario.

Pero la gestión de esas credenciales y la responsabilidad que conlleva son una tarea de gran complejidad y coste operativo, innecesario muchas veces. Las situaciones en las que es realmente estratégico conocer y gestionar esos datos de identificación real se reducen a casos muy aislados, por ejemplo:

• Redes sociales en los que la identidad del usuario sea relevante, como son las redes sociales profesionales.
• Servicios que requieren facturación directa al usuario.
• Servicios u operativas que legalmente exijan el registro de esos datos, como por ejemplo las páginas de juego.

En la gran mayoría de los casos, no es estratégico o no aporta valor al negocio el conocer y gestionar esas credenciales. Y por el contrario, solo aportan tareas y complejidades operativas:

• Registro del fichero de datos personales en la Agencia de Protección de Datos (esto es particular de España, pero estoy convencido que es similar en otros muchos países).
• Implantación del Reglamento de Medidas de Seguridad de los ficheros de datos de carácter personal (igualmente, propio de España, pero aplicable de manera análoga en otros países).
• Restricciones en cuanto a la ubicación física de componentes si hubiese algún tipo de restricción legal a respecto (nuevamente, en España, la legislación de protección de datos no permite ubicar el fichero fuera del país, al menos sin unas fuertes limitaciones, ver Título V de la LOPD).
• Controles de seguridad y metodologías de desarrollo más complejas y costosas, así como procedimientos de Gestión de Incidencias.

Y se acompaña a su vez de un conjunto de riesgos a tener en cuenta también:

• Riesgo reputacional, que sufre la imagen de la empresa o su credibilidad técnica y operativa si sus sistemas de autenticación son rotos.
• Riesgo operacional, que conlleva el hacerse cargo de los costos o pérdidas debidas al fraude cometido.
• Riesgo operativo por disponibilidad de servicio, cuando nos veamos obligados a parar el servicio durante las tareas de investigación y subsanación de un problema de seguridad.
• Riesgo legal, cuando el fraude conlleva además responsabilidades legales.

Seguro que Sony nos puede hablar muy bien del impacto de todos ellos.

Por estos motivos, el acompañar a nuestra aplicación de funcionalidades de registro de usuario, así como de identificación, es en muchas ocasiones innecesario. No estoy queriendo decir que no personalicemos el comportamiento del aplicativo (Gestión de Perfiles de Usuario o Personalización), ni que no protejamos las diferentes funcionalidades o servicios (Autorización); que siguen siendo muy necesarios. Me estoy refiriendo a hacer uso de los sistemas de autenticación y credenciales de terceros para usarlos en nuestro aplicativo o servicio.

Esta práctica empieza a ser muy común. Usando estándares como OpenID o OAuth, los diferentes servicios Internet ceden la gestión de credenciales a terceros de confianza, como Google y Facebook entre otros, y se aprovechan de sus credenciales para autenticar a los usuarios, para gestionar su perfil o para autorizar los diferentes servicios que proveen.

Estas prácticas tienen una serie de ventajas inmediatas:

• Es más cómodo para el usuario, que no tiene recordar unas nuevas credenciales, ni tiene que registrarse en el servicio. Simplemente usa las credenciales del tercero donde ya se ha registrado. La personalización del servicio o gestión del perfil del usuario, así como la autorización de acceso a los diferentes servicios y recursos, se sigue haciendo pero con estas credenciales.
• Transferimos gran parte de los riesgos antes expuestos a este tercero, responsable ahora de la gestión e identificación de las credenciales. No olvidemos, de todas maneras, que mecanismos de seguridad de control de acceso y autorización siguen de nuestro lado, con todo lo que eso implica.
• Evitamos algunas de las tareas y complejidades operativas de las que hablábamos antes. En el caso de los datos de carácter personal esto es así siempre y cuando, una vez autenticados con la credenciales del tercero, no almacenemos datos de tipo personal; simplemente hagamos uso de los que nos llegan con las credenciales (ver artículo 12 LOPD).
• En algunos casos, mediante OpenId Attributes Exchange por ejemplo, es posible junto con las credenciales recibir algunos datos (de carácter personal, por cierto) del usuario, como son mail, nombre y nacionalidad. Estos datos, gestionados por el proveedor de credenciales y actualizados por el usuario, pueden ser explotados por nuestro servicio de una manera muy cómoda para el usuario, sin registros ni formularios. Ahora sí, cuando los solicitemos, el proveedor de credenciales consultará al usuario el acceso a los mismos por nuestra parte; lo que, además de una exigencia legal y de política del proveedor, es un mecanismo de transparencia y credibilidad muy bueno cara al usuario, en mi opinión.
• En el caso de aplicaciones Web, toda la lógica de autenticación contra el proveedor puede implementarse de manera segura en el navegador, no habiendo necesidad de hacerlo en el lado del servidor. Esto tiene ventajas en la carga y ancho de banda que soporta nuestra infraestructura.

Existen ya muchos servicios de Internet que autentican ya mediante Google Accounts, como es Rescue Time, o mediante Facebook, como Endomondo. El punto clave de esta solución es elegir correctamente a este tercero de confianza, y sobre todo hacerlo en línea con la política de alianzas o independencia que queramos mostrar (cara al usuario hacemos palpable y evidente que hemos cedido la gestión de identidades a un tercero).

Por lo tanto, ¿es necesario hacernos cargo de la gestión de credenciales?. La respuesta es depende. Sí, cuando las credenciales son parte estratégica de nuestro negocio o cuando exista algún imperativo legal que nos obligue a hacerlo; no, cuando no aporte ningún valor a nuestro negocio.

Un saludo.

Esta obra de Juan Francisco Adame Lorite está bajo una licencia Creative Commons Atribución-CompartirIgual 3.0 Unported.