El título de mi charla hoy es No es magia, y voy a hablar sobre elevar la seguridad de autenticación con las mejores prácticas de Pixie. Ahora, los estándares abiertos que actualmente usamos para el acceso a recursos con OAuth 2 y el inicio de sesión con OpenID Connect han existido por más de una década. Aunque OAuth 2 y OIDC son excelentes para la seguridad de aplicaciones, fueron escritos hace más de 10 años.
Las arquitecturas de aplicaciones son mucho más dinámicas ahora, la tecnología ha cambiado, y los atacantes han tenido mucho tiempo para aprender cómo explotar debilidades de implementación y anti-patrones. Así que en enero de 2025, el IETF publicó nuevas mejores prácticas para la seguridad de OAuth y OIDC. Ahora, esta es una charla relámpago, así que solo voy a cubrir una forma de mejorar la seguridad para aplicaciones web, y eso es usando Proofkey for Code Exchange, o PIXIE.
PIXIE es una capa adicional de seguridad sobre el flujo de código de autorización. Este flujo funciona así. Digamos que tienes tu aplicación Node viviendo en tu servidor, y luego tienes un servidor de autorización. Ahora, esto es realmente solo una palabra elegante para un conjunto de endpoints para emitir tokens. El servidor de autorización podría estar alojado localmente en tu propia infraestructura o en la nube. Ahora, cuando un usuario llega a tu sitio, en el navegador, van a recibir un aviso para iniciar sesión, y en el lado del cliente, vas a crear una cadena aleatoria de alta entropía. Esto se llama nuestro verificador de código.
Ahora, también tenemos una función de hash llamada el método de desafío de código. El hashing es irreversible, así que una vez que una cadena es hasheada, no se puede deshashear. No hay forma de volver a la entrada original. Usando esta función, hasheamos el verificador de código para calcular una cadena de salida hasheada, que vamos a llamar el desafío de código. Luego tomamos la solicitud de autorización y el desafío de código, y opcionalmente el método de desafío de código, y enviamos esto al endpoint de autorización del servidor de autorización. El servidor de autorización autentica al usuario final, y luego genera un código, que se envía al navegador en una cadena de consulta de URL.
Ahora, en el flujo de código de autorización normal sin Pixie, no hay verificador de código, y en este punto, la aplicación intercambiaría el código por tokens que identifican al usuario o conceden acceso a recursos. Sin embargo, debido a que este código está expuesto en el navegador, un atacante podría potencialmente robarlo e intentar intercambiarlo por los tokens del usuario inyectándolo en su propia sesión. Esto se llama inyección de código de autorización. Pixie previene la inyección de código al vincular la solicitud de autorización con la solicitud de token. Una vez que la aplicación tiene el código, el código, el verificador de código, y la solicitud de token se envían al endpoint de token del servidor de autorización. El servidor de autorización confirma que el código es el mismo código que envió en respuesta a la solicitud de autorización de la aplicación. Este fue el que se entregó a la aplicación en la cadena de consulta. Ahora, el servidor de autorización también tiene el verificador de código, que es la cadena aleatoria que fue generada por el cliente al inicio de este proceso. Recuerda, enviamos el desafío de código, que es el verificador de código hasheado, y el método de desafío de código desde la aplicación al servidor de autorización cuando emitimos la solicitud de autorización. Esto ahora significa que el servidor de autorización tiene todo lo que necesita para hashear el verificador de código con el método de desafío de código en sí mismo. Lo hace y luego compara su desafío de código recién calculado con el desafío de código que la aplicación envió anteriormente, y si los desafíos coinciden, entonces los tokens se emiten y se entregan a la aplicación donde son validados.
Comments