Macaroons Escalaron Rápidamente
Los macaroons—tokens criptográficos con caveats, usados para autorización—se están explorando como una alternativa flexible a las cookies tradicionales y a JWT, con un atractivo particular para la delegación y el control de acceso granular en sistemas distribuidos. Los comentaristas examinan las compensaciones entre macaroons simétricos basados en HMAC y esquemas asimétricos como Biscuits o JWT, abordando el rendimiento, la gestión de claves, la revocación y el coste operativo de la verificación centralizada. A lo largo del debate, los lectores señalan la persistente confusión entre “macarons” y “macaroons” en nombres e imágenes, destacando cómo incluso la terminología puede complicar la adopción de nuevos mecanismos de seguridad.
Macaron vs. Macaroon (y otras tangentes lingüísticas)
- Gran subhilo sobre la diferencia entre macarons (galletas francesas tipo “sándwich” de merengue) y macaroons (montoncitos de coco).
- Varios señalan que la imagen del blog muestra macarons mientras que el esquema de tokens se llama “macaroons”; algunos toman “French macaroon” como un sinónimo aceptable, otros insisten en que eso está simplemente mal.
- La discusión se amplía hacia la deriva del lenguaje: entrada como “plato principal” en inglés estadounidense, “mains” en menús del Reino Unido, “macarrons/macaroni/maccheroni” como pasta, y bromas sobre “Macron/micron/mâcon/maçon”.
- Algunos ven la confusión en el nombre como marketing caprichoso; otros creen que elegir “macaroon” pese a la confusión existente fue una mala decisión.
Macaroons como tokens de autenticación: diseño, compensaciones y comparaciones
- Varios comentarios reafirman que los macaroons son tokens portadores que pueden atenuarse y delegarse sin contactar al emisor, a menudo comparados de forma laxa con una “cadena”, pero explícitamente no con una blockchain.
- Se enfatiza el modelo basado en capacidades: la autoridad fluye de la posesión de un token, no de identidades; esto se ve como una ventaja, pero complica la delegación autenticada y la auditoría.
- Se plantean preocupaciones: clave raíz simétrica única, rotación de claves, necesidad de verificación en línea, revocación, limitación de tasa y dificultad de auditar centralmente tokens derivados.
- El despliegue del artículo usa un servicio verificador que actúa como un HSM por software; esto se presenta como una mitigación de los riesgos de la clave simétrica y como una razón por la que biscuits (basados en clave pública) resultan menos convincentes aquí.
- Comparaciones con Biscuits, UCAN, JWT, Zanzibar y “runes”: los macaroons ganan en simplicidad, velocidad y compatibilidad con la era post-cuántica; biscuits y sistemas similares ganan en verificación sin conexión y lógica de políticas más rica.
- Algunos argumentan que la atenuación/delegación debería usarse más ampliamente; otros dicen que los macaroons son excesivos para aplicaciones CRUD simples.
Detalles de implementación, UX y documentación
- Se aclara que el Python del blog es pseudocódigo; el sistema real usa formatos tipados, AEAD, canales tipo Noise/mTLS y un manejo estricto de caveats.
- Los lectores piden una señalización más clara de código “de juguete” vs. “de producción” y más contexto sobre HMAC, atenuación y publicaciones previas.
- Algunos elogian la escritura y las ilustraciones; otros encuentran el tono ocasionalmente “inside baseball”.
- Discusión lateral sobre la DX de Fly.io: confusión acerca de máquinas de base de datos, credenciales y acceso a variables de entorno, vinculada a un modelo de seguridad deliberado que trata los secretos como “hazmat”.
Patentes y preocupaciones legales
- Se menciona una patente de Google sobre macaroons; algunos evitaron la tecnología por temor a infracción.
- Otros señalan las promesas de no agresión de Google y la práctica general de “patentes defensivas”, pero no está claro cuán vinculantes sean esas promesas en un tribunal.