自定义应用程序特定的，与安全性相关的HTTP标头是否违反了关注点分离，这被认为是一种不好的做法吗？我意识到使用自定义标头来控制服务将客户端与服务实现紧密耦合。或者在这种情况下，要控制安全框架的行为。我计划使用自定义标头的上下文如下：
我们正在使用基于令牌的身份验证，其中令牌具有固定的生命周期，并且每次经过身份验证的客户端调用Web API时都会发出新令牌。 SPA客户端可以在两种情况下使用AJAX调用服务器
现在，如果用户打开页面，会话永不过期，因为为每个自动提取生成了新标记。 不知何故，我们需要区分用户操作和服务器端的自动刷新，并仅为用户操作发布新令牌。
我意识到基于Websocket的刷新将是一个解决方案，但我们已决定坚持定时AJAX调用特定事项。另一种解决方案是将令牌刷新作为单独的端点提供，但这从客户端的角度来看违反了DRY原则，并且使用Spring Security进行设置会更加麻烦。
只有剩下的选项是将用户/自动信息嵌入到请求本身中，使用标题似乎是一个可行的选项。某些标头的存在会阻止令牌刷新。只需几行代码即可轻松实现。
我唯一担心的是，如果这会将客户端与服务实现过多联系起来。从技术上讲，它不会将客户端与服务相结合，而是与前面的安全过滤器相结合，从而泄露了用户界面中的安全问题。理想情况下，安全性应该对用户界面透明，因此可以在不知道任何安全性的情况下对新客户端进行编码（特别是在使用cookie时）。
另一方面，这种解决方案不具有破坏性或变异性。它是一个可选功能。通过客户端使用它，安全性得到了增强，但在任何一种情况下都没有减少（从服务器的角度来看，实际上是这样）。现在的问题是，使用可选标头来增强安全性的原则是违反的，在这种情况下它是否是一个有效的解决方案？
在我的选项中，应该透明地最大化安全性，但在这种情况下，我不知道如何不泄漏客户端的安全问题。
答案 0 :(得分：0)
听起来您在这里使用自己的家庭自定义令牌身份验证解决方案。这不是一个好主意。
我会花一点时间来解释为什么你不想做你提出的建议，然后选择更好的选择。
首先 - 您在此尝试解决的问题是，如果用户打开标签页，您不希望用户永远保持登录您的网站。您需要解决这个问题的原因是因为现在，您需要在用户的每次请求中分配新的访问令牌。
处理上述问题的正确解决方案是拥有两种类型的令牌。
具有非常短的生命周期的访问令牌（让我们说：1小时），以及具有更长生命周期的刷新令牌（让我们说：24小时）。
的工作方式是：
此流程有许多好处：
上述流程的优点在于它是一种网络授权标准：OAuth2。
OAuth2密码授予流程完全符合您的描述。它生成两种类型的令牌，句柄和刷新＆＃39;代币，以安全，符合标准的方式从头到尾处理整个事物。
我强烈建议您在服务器和客户端上实施OAuth2库，这将满足您的这些需求。
现在 - 关于令牌，现在大多数OAuth2实现一天都会生成令牌JSON Web Tokens。这些是加密签名的令牌，提供许多安全性好处。
无论如何：我希望这有用！我在Python，Node和Go中编写了几个流行的身份验证库 - 所以这来自我在过去几年中使用这些协议的直接经验。