这是一个概念性的问题，它涉及到这样一个事实：在Spring Security 中，身份验证具有不同的级别。
有一个等级
匿名身份验证也称为 IS_AUTHENTICATED_ANONYMOUSLY 还记得我吗 IS_AUTHENTICATED_REMEMBERED 完全身份验证，当用户仅提供其全部凭据并得到确认时 IS_AUTHENTICATED_FULLY 在执行 AuthenticatedVoter#isFullyAuthenticated 很明显，完全经过身份验证的用户不能 anonymous authenticated 或 remember-me authenticated .
我完全理解我们为什么要区分 IS_AUTHENTICATED_FULLY 及 IS_AUTHENTICATED_ANONYMOUSLY ，我真的不明白为什么 IS_AUTHENTICATED_REMEMBERED 不平等对待 IS_AUTHENTICATED_FULLY .
我是如何理解并记住我的：
我的理解是，记住我是使用某种秘密令牌的身份验证—使用此令牌，我们加载一个现有的 SecurityContext 其中已经包括完全认证的 Authentication 在初始化过程中写入的对象 full authentication . 在这方面，它基本上恢复了完全身份验证。
与会话登录相比，会话登录具有类似的令牌，但在SpringSecurity中考虑了完全身份验证，为什么记住我和基于会话的登录之间存在差异？
问题:
考虑到记得我恢复了一个完整的身份验证 SecurityContext ，应用程序逻辑将上下文视为正常的完全身份验证。
如果我们在应用程序中为完全经过身份验证的用户提供了一些逻辑，那么它肯定也适用于Remember me经过身份验证的情况。
当然，为了 anonymous authenticated 我们的用户通常有不同的决定要做，所以我理解为什么要把它挑出来。
我是否理解“以错误的方式记住我”的概念，或者不计算用户的确切原因是什么 remembered 完全认证？
1条答案
按热度按时间pkbketx91#
与会话登录相比，会话登录具有类似的令牌，但在SpringSecurity中考虑了完全身份验证，为什么记住我和基于会话的登录之间存在差异？
通常情况下，您的会话超时时间低于Memory me令牌的生命周期。根据spring的文档，RememberMe令牌的寿命为2周，而会话超时通常仅定义为分钟。
请记住，我可以被认为类似于恢复超时的会话，但这与恢复安全上下文一样不安全。为什么？
一般来说，您希望应用多个安全层，但作为应用程序开发人员，有些安全层您无法控制（至少不能直接控制），例如：
无法保证用户不会共享其凭据（用户名/密码），因此可能需要多因素身份验证。
不能保证经过身份验证的用户离开他们的机器并且不锁定它。在这种情况下，其他人可以访问应用程序，因此您希望令牌尽可能短。因此，许多应用程序在关键操作中使用额外的令牌，例如，当我可以将产品放入amazon上的购物车时，但当我想下订单时，我需要重新验证以确保它确实是我。
基本上，这是“记住我”增加的第二个风险：如果用户正在积极使用应用程序，您只能假设用户仍在其机器前面，因此您希望尽可能缩短会话超时时间，以快速确定用户是否处于非活动状态（并且寿命足够长，以保持良好的可用性水平）。
记住我会重新激活一个不活动的会话（或者至少是相关的安全上下文），因此这里您假设现在在机器前面的用户是原始用户。这是无法保证的，因此请记住，身份验证可能会被认为不太安全。
oauth刷新令牌可以被视为类似的东西：当用户成功通过身份验证时，您将获得一个访问令牌，但无论活动如何，访问令牌都将过期。然后，如果会话仍然处于活动状态（这并不保证用户正在或没有更改），您将使用刷新令牌来获取新的访问令牌。
因此，在安全性方面，不考虑身份验证选项，我将按照以下顺序对它们进行排序：
通过显式身份验证用户检索的访问令牌：将其用于关键操作，使其短暂，并且不为这些操作提供刷新令牌
通过刷新令牌检索的刷新令牌和访问令牌：基本上与会话安全性相当，因为刷新令牌的生命周期通常与会话生命周期相关（如果用户在时间x内未访问受保护的资源，则访问令牌和刷新令牌都将过期，用户需要重新验证）。请注意，刷新令牌不应与用户共享。
RememberMe令牌：可以被视为与用户共享的长寿命刷新令牌的一种形式