I have two sites on separate domains. I'm implementing SSO using the Thinktecture IdentityModel.
A user logs into Site A. At some point they click a link to take them to site B. Site A redirects the user to site B/Login.aspx?token=< token > with a JWT token. Site B then validates the token by calling an API on Site A to authenticate the user. If authenticated, the user is automatically logged into site B.
By default Thinktecture tokens last for 10 hours, with no way to kill a token(as far as I can tell). If the user logs out of the site, the token is still valid. I can look at the browser history and get the "Login.aspx?token=< token >" url and be automatically logged back in. Is there a way to kill all of a users tokens when they logout? Should the token not be passed as part of the querystring? What is the best way to prevent a replay attack?
As commented on your question by @leastprivilege, you can easily achieve SSO for both your sites just by defining both sites as RP's (relying parties) trusting the same IDP. That would of course simplify your authentication solution architecture.
Having said that, passive authentication using WS-Fed, is still vulnerable to replay attacks. Although the token is posted to your site, hitting "back" on your browser a couple of times (even after sign out) will re-post the token to your site and will sign the user back in.
Fortunately, WIF has a way to mitigate that attack. By configuring:
<identityConfiguration>
.......
<tokenReplayDetection enabled="true" />
.....
</identityConfiguration>
Wif then caches the used token on the server and makes sure it is used only once. (A proper exception is raised if a replay attack is detected SecurityTokenReplayDetectedException).
This cache of course will not survive a process recycle and won't be enough in a web farm scenario. If you want to mitigate this attack for these scenarios as well, you would need some kind of distributed & persistent cache for it.
I implemented one as a contribution to Thinktecture.IdentityModel, you could look into it and use it.
Sounds like POSTing tokens should resolve the issue, at least in this most obvious scenario you describe. Haven't used JWT tokens but SAML tokens are usually POSTed. I bet the server can be configured to post jwt tokens as well.
