In RFC5054, the SRP6a algorithm states that the client and the server should generate random ephemeral private values $a$ and $b$ respectively which are used for further derivation in the handshake and in the generation of the shared-key. For a persistent TLS connection, it obviously makes sense to generate a new random $b$ value each time a client connects.
Edited for clarity: However, I would like to use SRP in a stateless authentication handshake over multiple HTTP requests. The first request would be the client sending its $I$ to the server, and it would receive ($N$, $g$, $s$, $B$) in return. The client would the calculate $A$ and make another request to confirm its identity. Since the second request may hit a different server, this implies that the private $b$ would have to be shared across all servers. The simple solution is a constant value shared by all servers.
Aside from replayability, does choosing a random but constant $b$ value across all servers have any other security implications? Should I definitely not do this? Would silly tricks, like a varying time-windowed values derived from a constant $b$ be a better choice?
My instinct tells me this is roughly fine, in the same way that we use random-but-constant secrets to secure, e.g. session cookies, but I want to understand the implications.
To be clear, I'm only using this for authentication purposes so that the server never sees the user's password, and depending on TLS for forward secrecy of subsequent communications. I realize I could also, for example, bcrypt the user's password before sending it to the server to achieve similar goals, but thought it might be better to use a degraded version SRP instead.