nul*_*ter 9 security authentication cookies jwt asp.net-core
我正在使用Angular 2和ASP.NET Core Web API中内置的后端服务来构建Web应用程序。
对于身份验证，我正在考虑使用JWT令牌并将其存储在安全的HttpOnly Cookie中。
为了提高安全性，我还考虑在初次登录时以及初次登录后的每个请求中为用户捕获IP地址，如果IP地址更改，则吊销令牌。
所以我的问题是：
（响应一个答案）。
谢谢你回答我的问题。我已经回复了您的一些回复。
我最初的想法是，在cookie中使用JWT连接到API并不是典型的用例，为什么不使用标准MVC应用程序，但这不是您的问题，实际上，只要令牌是安全的，它同样安全在安全的httponly cookie中（当然实现是正确的）。我认为这有点不寻常。
我不确定您为什么考虑以这种方式使用Cookie异常？
是因为大多数时候cookie都用于会话状态吗？我个人认为，将令牌存储在安全的cookie中而不是将其保留在标http头或本地存储中应该是一个非常典型的用例，因为它的安全性更高。除非我想念什么？
因此，我想我会问这样做的缺点是什么？
这取决于。如果您担心会话被盗，可能是的。如果将令牌保存在httponly cookie中（针对xss进行了保护），则它比其他任何地方的令牌都更安全，但是，威胁模型仍可能显示不同的威胁并验证您的关注。通常的问题是您无法执行此操作，请参见下文。
该应用程序将处理许多PPI信息，因此我确实对令牌盗窃有所关注。
很有可能会有问题。这取决于您的用户，他们如何以及从何处使用您的应用程序。如果他们使用移动设备，则IP地址将发生很大变化，而这样的解决方案是不可能的。如果他们是公司内部网络中的公司用户，那将是可行的。它们之间是灰色区域。典型的家庭用户会不时更改其IP，大多数人会从其互联网提供商处获得动态IP分配。IP租约通常可持续数周（至少在我居住的地方），但是ISP可以根据需要配置它，可能需要一天甚至更短的时间。
我对IP地址租约续约的印象是，大多数情况下，客户端会获得相同的IP地址。但是，我不应该做出我认为的假设吗？
但是我可以看到，这对于移动设备来说可能是一个更大的问题。有些客户经常出差，所以这是您提出的一个好问题，可能会成为问题。
您可以选择执行的一种典型解决方案是在登录屏幕上提供此选项。如果用户选择使用IP地址验证，则他会选择更高的安全性，但会接受有时可能不得不再次登录的事实。或者，他可以选择较低的安全性，使其会话更稳定。我认为是否值得向您的用户解释这一点是一项商业决策。
从未考虑过给客户一个听起来不错的选择。
（响应一个答案）。
另外，我不确定您的JWT是否只有一个会话ID，或者您的服务器是否为无状态且所有会话数据都在JWT中。在第一种情况下，您甚至不需要JWT，您可以像往常一样传递会话ID，而标准的.Net MVC可以为您实现。如果它也是会话数据，则JWT默认情况下未加密，因此会话内容对于最终用户将是可见的，这可能是问题，也可能不是问题。（而且，JWT的签名受到保护，不会被篡改，因此它仅是关于机密性，而不是完整性）。根据您的目标浏览器，将会话数据存储在JWT中以及将JWT存储在cookie中也可能会遇到cookie大小问题。
我的后端ASP.NET Core Web API将是无状态的。已经做出使用决定，Angular因此讨论是有争议的。
至于为什么我认为以这种方式使用JWT有点不寻常：我认为JWT通常在需要将令牌传递到不同的URL（传递到不同的服务）时使用。为此，由于相同的原产地规则，httpOnly cookie显然不足。如果您负担得起使用httpOnly cookie的费用，则可以将会话信息存储在服务器端。
由于我的解决方案可能存在缺陷，我很想讨论上述主题，我认为可能会关闭这篇文章的话题吗？
提出针对上述主题的新问题也许更合适？
至于产生相同IP的租约续约：嗯，它们并不总是如此。这取决于您的业务情况，但是某些ISP仅在短时间内为您提供IP。如果您的用户偶尔可以注销，那么有线（家庭）用户也可以。对于移动设备，这绝对是一个大问题。
我最初的想法是在 cookie 中使用 JWT 连接到 API 不是典型的用例，那么为什么不使用标准的 MVC 应用程序，但这不是你的问题，实际上它同样安全，只要令牌是在安全的 httponly cookie 中（当然实现是正确的）。我觉得这有点不寻常。
关于这一点，您的问题非常有效，您对问题的关注也是如此。
这种额外的安全级别值得吗？
这取决于。如果您担心会话被盗，可能是的。如果您将令牌保存在 httponly cookie（防止 xss）中，这比其他任何地方的令牌更安全，但是，您的威胁模型可能会显示不同的威胁并验证您的担忧。通常的问题是你不能这样做，见下文。
我正在考虑使用的 IP 检查会不会有任何问题？
很可能，会有问题。这取决于您的用户，他们使用您的应用程序的方式和地点。如果他们使用移动设备，IP地址会发生很大变化，这样的解决方案是不可能的。如果他们是公司内部网络中的公司用户，这是可行的。介于两者之间的任何东西都是灰色区域。一个典型的家庭用户会偶尔更改他们的 IP，大多数人从他们的互联网提供商那里获得动态 IP 分配。IP 租约通常持续数周（至少在我居住的地方），但 ISP 可以按照他们想要的任何方式进行配置，可以是一天甚至更短。
所以现实是，如果你有一个正常的、普通的用户群，你很可能会遇到问题。
您可以选择的一种典型解决方案是在登录屏幕上提供此选项。如果用户选择使用 IP 地址验证，他会选择更高的安全性，但接受有时他可能必须再次登录的事实。或者他可以选择较低的安全性，而他的会话更稳定。我认为是否值得向您的用户解释这一点是一个商业决策。
更新以响应编辑 1 :)
至于为什么我认为以这种方式使用 JWT 有点不寻常：我认为 JWT 主要用于需要将令牌传递到不同 URL（到不同服务）的情况。为此，由于同源规则，httpOnly cookie 显然是不够的。如果您负担得起使用 httpOnly cookie，您可以将会话信息存储在服务器端。另外，我不确定您的 JWT 是否只有会话 ID，或者您的服务器是否是无状态的并且所有会话数据都在 JWT 中。在第一种情况下，您甚至不需要 JWT，您可以像往常一样传递会话 ID，标准 .Net MVC 会为您完成。如果它也是会话数据，默认情况下 JWT 是未加密的，因此最终用户可以看到会话内容，这可能是也可能不是问题。（并且 JWT 受到其签名的保护而不会被篡改，因此它' s 只是关于机密性，而不是完整性）。将会话数据存储在 JWT 中并将 JWT 存储在 cookie 中也可能面临 cookie 大小问题，具体取决于您的目标浏览器。
至于导致相同 IP 的租约更新：嗯，它们并不总是如此。这取决于您的业务案例，但某些 ISP 仅会在短时间内为您提供 IP。如果您的用户可以偶尔注销，那么有线（家庭）用户可能没问题。这绝对是移动设备的一个大问题。