我在IIS后面的服务器中部署了一个ASP.NET核心REST API。REST API由Angular JS Web应用程序和Mobile(Android/IOS)应用程序使用。对于授权，我使用JWT令牌()。最近通过了安全审计，他们发现存储在本地存储中的JWT可能会被同一组织的其他攻击者窃取并用于冒充(例如，员工利用经理的功能)。
我想将个人或机器标记为JWT，这样当JWT被盗时，攻击者就不会滥用它，也不会对被盗的代币有任何用处。我尝试用JWT标记IP，并将这些查找存储在服务器(内存缓存)中。下面是我尝试过的代码，但没有成功。
private readonly IHttpContextAccessor _httpContextAccessor;
public TestController(IHttpContextAccessor httpContextAccessor)
{
_httpContextAccessor = httpContextAccessor;
}
var ipAddress = _httpContextAccessor.HttpContext.Connection.RemoteIpAddress.ToString();
每次我从不同的机器请求时，我都希望输出不同。但每次的实际输出都是相同的IP，比如15.11.101.25(尽管我尝试了不同的机器)。如果有更好的解决方案，请与我分享。对不起我的英语。
如果您真的需要这种安全性，您可以将JWT令牌与一个安全的(=仅允许通过https发送的cookie)http only cookie相结合，并在其中存储一种在每次请求时发送的请求令牌。
您可以阅读JWT的存储位置-Cookie与HTML5 Web存储，其中涵盖了主题，并解释了JWT本地存储与Cookie的上下两面。
Http-only cookie不能通过JavaScripts读取(因此不会被盗)，因此可以安全地抵御XSS攻击。基于CSRF的攻击无法获得JWT令牌(因为它是通过标头发送的)。
因此，基于XSS的攻击不会有基于cookie的令牌，基于CSRF的请求也不会有对用户进行身份验证所需的JWT令牌。cookie令牌可以在登录时生成，因此它与登录该机器的用户绑定。
当然，您也可以扭转局面，将JWT放在一个安全的cooke中，并将反请求令牌作为标头。
当然，你仍然可以通过对机器的物理访问来窃取防伪cookie，但这既不是XSS也不是CSRF，而且不能单独受到应用程序的保护，机器本身需要受到物理类型的攻击。
或者，不要将JWT令牌存储在本地存储中。当你使用OpenID流时，你的应用程序在第一次加载时会发现它没有被授权，会将你重定向到OpenID提供者，让用户输入他的凭据，并使用令牌(或身份验证代码流的代码)将其重定向回。
当用户关闭浏览器并再次打开网站时，不再有令牌，用户将被重定向到OpenID提供商。由于用户仍在登录，因此不会询问任何凭据，并且他将被重定向回他来自的页面，包括一组新的令牌。您只需要将当前应用程序会话的令牌存储在内存中(并在其过期时刷新)。