![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(233.6, 54%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EJ%3C/text%3E%3C/svg%3E)
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(12.8, 62%, 11%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EH%3C/text%3E%3C/svg%3E)
Hola Jgarcia
Este comportamiento suele ser esperado en entornos SAML. Cuando un usuario utiliza el botón Atrás del navegador, puede intentar volver a env ar una SAML Assertion que ya fue consumida, por lo que el Service Provider la rechaza como medida de protección anti-replay.
Como práctica recomendada, mantenga una caché anti-replay basada en el Assertion ID durante el período de validez de la aserción y configure tiempos razonables de expiración (NotOnOrAfter). En lugar de permitir reutilizar la misma aserción, lo ideal es generar una nueva solicitud de autenticación cuando el usuario regrese a una página protegida. También recomiendo revisar si las respuestas SAML están siendo almacenadas en caché por el navegador y deshabilitar dicho comportamiento en los endpoints de autenticación.
Si esta respuesta le ha resultado útil, le agradecería que hiciera clic en "Aceptar respuesta"