Este es un diseño roto porque un GUID no debe ser secreto, sin embargo, según entiendo, proporciona un acceso idéntico al ingreso de su nombre de usuario y contraseña en el sitio web.
En teoría el diseño es sólido. Proteja el GUID como si fuera la contraseña del usuario y el caso cerrado.
En la práctica esto presenta muchos problemas.
Ejemplo: empiezo a trabajar en su empresa hoy. Me piden que escriba una función de búsqueda para que pueda encontrar a otros usuarios por dirección de correo electrónico. Probablemente codificaría los resultados de la búsqueda como una página que muestra una lista de enlaces a perfiles, que contiene algo como <a href="/user/${user.id}">${user.name}</a> . Al verificar qué columnas usar, descubro que el campo id se llama guid y el campo de nombre se llama fullName . Pruebo esto Funciona. Presiono el código.
Sin darme cuenta, acabo de filtrar el GUID del usuario que básicamente proporciona acceso completo a la cuenta. Ahora puede secuestrar cualquier cuenta de la que yo sepa la dirección de correo electrónico.
En este momento, el programador puede tener constantemente en mente que saber que el GUID proporciona acceso completo a la cuenta, pero en unos pocos meses ya no será algo en lo que piense mucho. Dado que es, supongo, la única forma única de apuntar a una cuenta, debe usarla en muchos lugares. Especialmente para la interacción del usuario, esto puede ser un problema (quizás los usuarios pueden formar compañías o grupos, compartir carpetas, lo que sea).
Una mejor manera sería separar la identificación y la autenticación. El GUID identifica un usuario, mientras que un token de seguridad autentica un usuario. Esto completa las partes de Identificación, Autenticación y Autorización (IAA) de un sistema de seguridad: el sistema decide la Autorización basada en la Identificación después de verificar la Autentificación. Por esta razón, además de las contraseñas, también necesitamos para completar un nombre de usuario en los sitios web. Usar solo uno u otro es generalmente una mala idea.
Todos los lugares donde se usa el GUID actualmente deben reemplazarse con los tokens de seguridad recién generados. Por ejemplo, una solicitud podría tener este aspecto: /API/2.0/doAction?GUID=${user.guid}&token=${some_security_token} . Tenga en cuenta que estos tokens deben ser completamente aleatorios (las probabilidades de adivinar deben estar alrededor de 1 en 2 ^ 128 ).
Hay muchas formas de generar estos tokens de seguridad. Muchos sitios web generan sesiones, pero también puede utilizar un campo de base de datos adicional. Cada vez que se realizan llamadas a la API, el usuario se autentica mediante este campo aleatorio. El campo debe llamarse algo que deje en claro que no se supone que otros deben saberlo.
Una vez más, en teoría no hace una gran diferencia en el diseño del sistema, ya sea que use un GUID aleatorio u otro campo generado aleatoriamente para la autenticación, pero en la práctica creo que sí previene muchos errores de seguridad grandes, especialmente cuando el sitio tiene algún tipo de interacción del usuario (pero también si no lo tiene, por ejemplo, una función de restablecimiento de contraseña puede exponer accidentalmente el GUID después de ingresar un nombre de usuario o una dirección de correo electrónico). Simplemente reduce el número de posibilidades de ataque.