Kerberos as used in HTTP is no different, really, and you get no benefit from having a replay cache in that case (or the vast majority of Kerberos use cases).

Kerberos as used in HTTP is no different, really, and you get no benefit from having a replay cache in that case (or the vast majority of Kerberos use cases). Once we're talking HTTP, you really depend on server certificates for security. Attempts to perform "channel binding" or "token binding" in HTTP to alleviate the dependency on server certificates for security have mostly failed due to complexities having to do with reverse proxies and availability of necessary APIs. Signed JWTs have the benefit of not having to first establish shared secrets with a trusted third party. The relying party need only fetch and cache the JWKs and validate the signatures on incoming JWTs. SAML, OIDC, and such, sometimes can resemble Kerberos too. Their benefit lies in not needing HTTP clients to have any smarts, whereas "Negotiate" (RFC4559) does. SAML and OIDC accomplish this by relying mainly on redirect chasing by the client, though as a trade-off they get to deal with the problem of open redirectors.