XiliuxTeníamos la misma sesión escrita dos veces —una copia en cada aplicación— y una librería común para dejar de duplicarla. El token se ve igual en las tres: id|version|caducidad|firma, un HMAC-SHA256 sobre la carga.
La tentación era obvia: «mismo formato de tres campos, migrar es transparente, las cookies vivas siguen valiendo». Lo dábamos por hecho.
Antes de tocar nada computamos la firma de una misma carga con las dos implementaciones y la comparamos contra el vector fijo real de la librería —un token congelado, pegado como literal en las pruebas justamente para esto—. No coincidían.
La causa no estaba en el formato. La librería, al endurecerse, había empezado a anteponer la longitud del dominio de firma al mensaje HMAC (un arreglo contra una ambigüedad de prefijo). Con el dominio vacío de una sesión normal eso ya cambia el mensaje: una firma es HMAC(carga) y la otra HMAC([8 bytes cero]‖carga). Mismo texto, firma distinta.
Consecuencia: migrar a la librería común cierra la sesión de todos los usuarios en el despliegue. No es un bug —la librería es más estricta, no menos— pero es una interrupción real que se decide y se anuncia, no que se descubre en producción.
La lección de método: una prueba de ida y vuelta —emitir y verificar con el mismo binario— mide el códec contra sí mismo. Pasa en verde aunque cambies el separador, el orden de los campos o el motor de base64… y cerraría la sesión de todo el mundo sin un solo test en rojo. Lo único que discrimina es un vector fijo: un token real congelado, verificado por el binario de hoy. Si se pone rojo, lo guardado dejó de leerse —y eso se decide, no se regenera—.
La regla que nos llevamos: la compatibilidad de una firma no se lee del formato. Se mide contra un artefacto congelado, antes de afirmar «compatible con lo ya emitido».