我正在使用Angular 2和ASP.NET Core Web API内置的后端服务构建Web应用程序。
对于身份验证，我正在考虑使用JWT并将令牌存储在Secure 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受到其签名的篡改保护，所以它只涉及机密性，而不是完整性）。将会话数据存储在cookie中的JWT和JWT中也可能会遇到cookie大小问题，具体取决于您的目标浏览器。
我的后端ASP.NET Core Web API将是无状态的。已经决定使用Angular，所以讨论是一个有争议的问题。
至于为什么我认为使用JWT这种方式有点不寻常：我认为JWT主要用于需要将令牌传递给不同的URL（到不同的服务）。出于这个目的，httpOnly cookie显然是不合适的，因为相同的原始规则。如果您能够负担得起使用httpOnly cookie，您只需将会话信息存储在服务器端。
就像我想讨论上述主题一样，因为我的解决方案可能存在缺陷，我认为这些权力可以关闭此帖子以获取主题？
可能更适合提出针对上述主题的新问题？
至于续租，导致相同的IP：嗯，他们并非总是如此。这取决于您的业务案例，但有些ISP仅在短时间内为您提供IP。如果您的用户偶尔可以注销，那么对于有线（家庭）用户来说可能没问题。这绝对是移动设备的一个大问题。
答案 0 :(得分：2)
我最初的想法是，在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受到其签名的篡改保护，所以它只涉及机密性，而不是完整性）。将会话数据存储在cookie中的JWT和JWT中也可能会遇到cookie大小问题，具体取决于您的目标浏览器。
至于续租，导致相同的IP：嗯，他们并非总是如此。这取决于您的业务案例，但有些ISP仅在短时间内为您提供IP。如果您的用户偶尔可以注销，那么对于有线（家庭）用户来说可能没问题。这绝对是移动设备的一个大问题。
答案 1 :(得分：0)
我认为您可以使用JWT和IP做到这一点。用户登录时。在会话期间捕获IP。在每次登录时，Capture IP都会使用该IP来验证令牌是来自启动会话的所有者。如果另一个IP命中了系统。强制重新验证和新令牌。 IP + JWT +密码=登录名。如果您的移动应用程序需要1次登录，请务必记住该登录信息。用户无需再次输入登录名。然后将用户ID \密码{安全地}缓存在应用程序中，然后在IP更改时自动重新发送它。使用SSL Difference between SSL and JWT
时，JWT是安全的答案 2 :(得分：0)
抱歉让我重提这个问题，但最近我一直在思考加密和安全问题，并想到了一些东西（我猜这与 HTTPS 的作用非常相似）
当用户登录时，服务器以正常的问候语（用户信息、JWT 以及您需要传递的任何其他数据）进行响应+您将传递一个公钥
有一个支持任何非对称加密方法的后端（我喜欢 RSA），并让你的前端（也需要运行相同的加密方法）接收公钥，加密数据，然后将它发送到服务器请求。
如果用户需要提供的任何数据发生变化，则撤销。
您甚至可以跟踪时钟，如果它关闭太多，则取消。
对于额外的层，让客户端在登录/注册和繁荣时传输公钥，像危险品套装一样密封通信。