As another example, suppose that a user opens a browser on a public kiosk, logs on to a bank account using the bank’s Web site, logs off and leaves, but does not close the browser. The response to the user’s logon page, which contains the STS token, is still in the browser’s history. Another person could then browse back to that response page and replay it, which would repost the STS token to the bank’s Web site.

To prevent this, WIF has a replay detection cache specifically for STS bearer tokens, which is just a cache of previously used STS tokens. When the client first authenticates to the RP using the STS token, it receives a session security token which it uses to authenticate to the RP for any additional requests. It does this over SSL so that the session security token cannot be stolen. If a client or an attacker tries to authenticate to the relying party with an STS token that the client has used already, the relying party can look up the STS token in the replay cache and refuse the request.

This cache does not guarantee that a token can never be replayed. It performs best effort detection based on the size of the cache, the expiry time of the STS token, and the rate of unique authentication requests received by the RP. It is strongly recommended that you tune the cache size and STS token expiry time for your RP to get the right balance between performance and security.

Note:
Replay detection is turned off by default. You can turn it on by setting DetectReplayedTokens to true.