管理令牌和会话

除了充当集中式身份验证和授权服务外，Keycloak 的核心还是一个会话和令牌管理系统。

作为身份验证过程的一部分，Keycloak 可以创建服务器端会话并将它们与令牌相关联。通过依赖这些会话，Keycloak 能够保持会话发起的身份验证上下文的状态，跟踪用户和客户端的活动，检查令牌的有效性，并决定用户和客户端何时应该重新进行身份验证。

在本章中，我们将了解 Keycloak 如何让您管理代币及其底层会话，并了解在执行此作时应注意的不同方面。为此，我们将涵盖以下主题：

• 管理会话

• 管理令牌

技术要求

在本章中，您将使用 Keycloak 管理控制台来遵循此处提供的一些示例；因此，请确保您已按照第 1 章 Keycloak 入门中学到的知识启动并运行 Keycloak。

管理会话

会话管理对一些关键方面有直接影响，例如用户体验、安全性、高可用性和性能。

从用户体验的角度来看，Keycloak 依靠会话来确定用户和客户端是否经过身份验证，他们应该被验证多长时间，以及何时需要重新验证他们。会话的这一特性基本上是用户在同一领域内对不同客户端进行身份验证时提供单点登录 （SSO） 体验的原因，也是使统一身份验证体验成为可能的原因。

从安全角度来看，会话提供了一个安全层，用于跟踪和控制用户活动，并确保颁发给客户端的令牌仍然是代表用户作的有效护照。它们对于限制和控制用户可以与 Realm 及其 Client 端保持连接的时间也很重要，有助于减少会话或令牌泄露或被盗时的攻击面。正如我们将在本主题后面看到的那样，管理员、用户和客户端可能会提前使会话失效，作为对恶意行为者未经授权的访问的反应或防止恶意行为者的未授权访问。

从性能角度来看，会话保存在内存中并分布在集群中的不同节点上，这对服务器运行时有直接影响。正如您在第 9 章 为生产配置 Keycloak 中学到的那样，Keycloak 将会话存储在共享缓存中，其中活动会话的数量、它们保持活动状态的时间以及它们的节点亲和性是需要平衡以优化网络、内存和 CPU 资源的关键因素。

考虑到所有这些，Keycloak 为您提供了灵活的会话和令牌管理，以平衡此处提到的所有三个方面。管理员应该能够跟踪用户和客户端的活动会话，检查用户对哪些客户端进行身份验证，强制单次或全局注销以使会话失效，撤销令牌，并控制会话和令牌生命周期的不同方面。

在下一个主题中，我们将开始研究如何管理会话的生命周期。

管理会话生命周期

在使用 Keycloak 进行生产之前，您需要回答的第一个问题是用户和客户端应该多久重新进行身份验证一次。为了帮助你解决这个问题，你应该了解 Keycloak 如何创建 session 以及如何定义它们的生命周期。

会话生存期确定会话何时过期并销毁。过期后，与这些会话关联的用户和客户端将不再进行身份验证，并被迫重新进行身份验证以建立新会话。

Keycloak 使用不时运行的后台任务使会话过期，以检查过期的会话。默认情况下，该任务每 15 分钟运行一次。如果您确实需要，您可以随意更改此值。对于大多数部署来说，默认设置应该足够了。

Keycloak 在对用户进行身份验证时在不同级别创建会话。首先，创建一个用户会话来跟踪用户活动，而不管客户端如何。第一级是所谓的 SSO 会话，也称为用户会话。在第二级，Keycloak 创建一个客户端会话，以跟踪用户在用户会话中进行身份验证的每个客户端的用户活动。客户端会话与令牌的有效性以及应用程序如何使用令牌密切相关。

作为顶级会话，SSO 会话生命周期是一个全局设置，用于控制用户和客户端需要重新进行身份验证的频率。Keycloak 允许您配置 SSO 会话应保持活动状态的最长时间，以及会话提前过期的空闲时间。当 SSO 会话过期时，与其关联的所有客户端会话也会过期。

SSO 会话类似于 HTTP 会话。两者都用于跟踪和维护来自同一代理的多个请求的状态。

要配置这些设置，您应该单击左侧面板上的 Realm Settings，然后单击 Sessions 选项卡：

图 12.1：配置 SSO 会话生命周期

在此选项卡中，您可以通过分别设置 SSO 会话最大值和 SSO 会话空闲设置来设置 SSO 会话的最大时间和空闲时间。这两个设置一起有效地告诉 Keycloak 会话应该保持活动状态一段时间，并且不会超过这个时间，同时，Keycloak 应该在一定时间内检查用户活动 - 空闲期 - 以决定会话是否应该提前过期。

让我们通过示例来了解这两个设置。默认情况下，Keycloak 为 SSO 会话定义了 10 小时的生命周期。这个时间实际上意味着会话最多可以持续 10 小时，并且不会超过这个时间。

但是，默认情况下，空闲超时设置为 30 分钟，这实际上意味着，如果 Keycloak 在 30 分钟内没有看到任何用户活动，则会话将被销毁，无论设置的最长时间如何。每次用户与 Keycloak 交互时，无论是直接通过授权端点（使用浏览器时），还是在客户端刷新令牌时间接交互，都会触发空闲超时。

如果用户进行身份验证并离开键盘，并且客户端在此期间未刷新其令牌，则用户会话将在 30 分钟内销毁。但是，如果用户不断使用浏览器与 Keycloak 交互，或者客户端不断刷新其令牌，则用户会话可以持续长达 10 小时。

与 SSO 会话一样，管理员可以设置 Client Session Idle （客户端会话空闲） 和 Client Session Max （客户端会话最大值） 设置，以分别设置客户端会话的空闲和最长时间：

图 12.2：配置客户端会话生命周期

这两个设置为管理员提供了对客户端会话生命周期的更精细的控制，从而可以定义令牌有效时间的硬性限制，并强制客户端在尝试刷新令牌时重新进行身份验证。换言之，颁发给领域中任何客户端的令牌仅在您设置的最长时间内有效，如果客户端在空闲期内未刷新其令牌，则可能会使客户端会话提前过期并使令牌失效。

但是，与 SSO 会话不同的是，当客户端会话失效时，如果用户的 SSO 会话未过期，则不必强制用户重新进行身份验证，但它会强制客户端重新进行身份验证以获取一组新的令牌。请注意，当客户端会话过期时，由于强制客户端重新进行身份验证，用户可能会被重定向到 Keycloak，这可能会对用户使用浏览器时的用户体验造成一些影响。

默认情况下，Keycloak 为 SSO 会话定义相同的配置集，以控制客户端会话生命周期。通过将 Client Session Idle （客户端会话空闲） 和 Client Session Max （客户端会话最大值） 设置的值更改为除 0 以外的任何其他值，您应该能够为客户端会话定义不同的生命周期。

正如您将在 管理令牌 部分中学到的那样，Keycloak 还允许管理员基于每个客户端覆盖 Client Session Max 和 Client Session Idle 设置。

根据经验，考虑到安全性、性能和用户体验方面，会话生命周期应尽可能短。通过使用较短的生命周期，您可以减少会话劫持攻击或令牌泄露或被盗的影响。它还避免了不显示任何用户活动的会话使服务器过载，因此有助于节省服务器资源，例如内存和 CPU。但是，较短的会话生命周期会直接影响用户体验以及用户需要重新进行身份验证的频率。在用户优先的方法中，您可能会从最适合用户的方法开始，然后根据您的安全要求以及您对硬件和基础设施资源的限制来调整会话生命周期。

在本主题中，您了解了如何管理会话生命周期及其对用户体验、安全性和性能的影响。您还了解到，在身份验证和令牌颁发过程中，Keycloak 可以基于每个用户创建一个 SSO 会话，并为用户进行身份验证的每个客户端创建客户端会话。

在下一主题中，您将学习如何跟踪和管理用户和客户端会话。

管理活动会话

Keycloak 为管理员提供了不同级别会话的良好可追溯性和可见性：

• 按领域

• 每个客户

• 每个用户

在领域级别，管理员可以查看每个客户端的活动会话数的统计信息。为此，请单击左侧面板上的 Sessions 链接：

图 12.3：管理领域的活动会话

在此页中，您可以单击任何客户端以获取有关其活动会话的更多详细信息。通过选择客户端，您应该被重定向到客户端详细信息页面上的 Sessions （会话） 选项卡。在此页中，您可以查看客户端中每个用户的活动会话，以及有关用户 IP 地址和会话启动时间的其他信息。

图 12.4.：管理客户端中的活动会话

通过单击此页面上的任何用户，您将被重定向到用户详细信息页面，这是活动会话的第三个也是最后一个可见性级别：

图 12.5：管理用户的会话

在用户详细信息页面上，您应该单击 Sessions 选项卡以查看用户的所有活动会话。在此选项卡上，您将获得有关会话的更多详细信息，例如会话何时开始、Keycloak 上次记录用户活动的时间以及与用户会话关联的所有客户端和客户端会话。

在正常情况下，您应该期望用户具有单个会话和多个客户端。在典型的 SSO 场景中尤其如此，当用户使用浏览器进行身份验证，并且同一会话被重复用于向不同的客户端进行身份验证时。但是，用户可能会关闭浏览器、清除 Cookie 或仅使用其他设备进行身份验证。在这些情况下，单个用户可能有多个用户会话，具体取决于他们使用您的应用程序的方式。

在本节中，您学习了如何更深入地了解领域中处于活动状态的会话。您还了解到 Keycloak 在每个领域、每个客户端和每个用户的基础上为您提供不同级别的可见性。最后，您了解到，在每个级别，您都会获得有关会话的其他信息。在下一主题中，您将更详细地了解这些不同级别的可见性，以及如何通过强制单个或全局注销来提前使会话过期。

提前终止用户会话

除了提供对活动会话的可见性外，Keycloak 还提供了在不同级别时提前过期会话的机制：

• Realm

• Client

• Use

在领域级别查看活动会话时，您可以通过单击 Action 选择框中的 Sign out all active sessions 作来使领域中的所有活动会话过期：

图 12.6：在领域级别强制会话过期

单击 Sign out all active sessions 后，Keycloak 将通过迭代所有会话并删除其引用来立即使所有会话过期。在此页面上，您还应该能够通过单击 Revocation 作来被动地撤销令牌，您将在下一节中学习。

在用户级别时，您可以通过单击 Sign out 链接使单个会话过期，或者通过单击 Logout all sessions 按钮来使所有会话过期：

图 12.7：过期的用户会话

当在用户级别过期会话时，Keycloak 可能会通过反向通道向应用程序发送通知，以便它们也可以使本地会话无效。有关更多详细信息，请查看文档 https://www.keycloak.org/docs/latest/server_admin/#backchannel-logout，了解如何在您的应用程序中处理注销事件。

请注意，当使用上述任何方法注销领域或用户级别的所有会话时，Keycloak 会迭代会话并逐个使它们过期。在用户级别，您不应期望很多活动用户会话，但可能会有许多客户端会话，具体取决于用户进行身份验证的客户端数量。但是，对于在领域中进行身份验证的每个用户，在领域级别过期会话可能是一项成本高昂的作。

在本主题中，您学习了如何使用 Keycloak 管理控制台提前终止用户会话。此外，还向您介绍了有关如何使用此处提供的不同选项使会话过期的一些注意事项。

在下一节中，您将了解 Keycloak 如何使用 cookie 来跟踪用户和客户端会话。

了解 Cookie 及其与会话的关系

如您所知，HTTP 是一种无状态协议，其中 cookie 通常用于在浏览器和服务器之间共享状态。当用户使用浏览器与之交互时，Keycloak 严重依赖 HTTP cookie 来跟踪用户会话。

成功对用户进行身份验证后，Keycloak 会设置一个 KEYCLOAK_IDENTITY Cookie，以将浏览器会话与服务器上相应的用户会话相关联。如果此 cookie 泄露或被盗，用户的会话可能会受到损害。

KEYCLOAK_IDENTITY Cookie 默认设置为 HttpOnly Cookie，以防止跨站脚本 （XSS） 和会话劫持攻击。它的过期时间基于设置为用户会话设置的最长时间的值，并且其值具有足够的熵来防止猜测攻击。

您可以为此 cookie 添加更多安全屏障，最有效的是确保 Keycloak 只能通过使用 HTTP over TLS （HTTPS） 的安全通道进行访问。使用 HTTPS 时，将 secure 属性设置为 Cookie，以防止其以明文形式传输，并将 SameSite=none 属性设置为确保 Cookie 仅通过安全连接在跨站点请求中发送。有关如何启用 TLS 的更多详细信息，请查看第 9 章 为生产配置 Keycloak

关于会话过期，KEYCLOAK_IDENTITY Cookie 在使用上一主题中介绍的任何方法时都不会自动过期。因此，浏览器可能仍会发送此 Cookie，但它们不再引用活动会话。收到无效的 cookie 后，Keycloak 将使其无效并强制用户重新进行身份验证。

在本主题中，您简要介绍了 Keycloak 如何使用 cookie 跟踪用户会话。您还了解了保护 cookie 对于确保用户会话安全至关重要，以及 Keycloak 如何帮助对它们执行严格的策略。

在本节中，您还了解了 Keycloak 中会话管理的一些关键方面。您了解到 Keycloak 会不断创建服务器端会话来跟踪经过身份验证的用户及其通过身份验证的客户端。您还了解了正确配置会话生命周期的重要性及其对应用程序和 Keycloak 的用户体验、安全性和性能的影响。最后，您看到了通过管理控制台使会话过期的不同选项，以及 Keycloak 如何在用户使用浏览器时利用 cookie 跟踪会话。

在下一节中，您将了解如何管理令牌及其与会话的关联。

管理令牌

正如您从上一节中学到的那样，令牌通常绑定到会话。因此，令牌的有效性（不一定是它们的生命周期）取决于会话。

令牌有自己的生命周期，它们被视为有效的时间长短取决于它们的验证方式。通过利用 JSON Web 令牌 （JWT） 作为令牌格式，Keycloak 使应用程序能够在本地验证和检查令牌，而无需与服务器进行任何额外的往返。但是，此功能会产生一个后果，即令牌尽管在其生命周期内，但如果其会话已过期，则可能不再有效。

如果不考虑到这一点，您最终可能会遇到令牌不再有效（它们必定要过期的会话）但仍被应用程序接受的情况，因为它们在其生命周期内，因此如果令牌泄露，则会增加攻击面。正如您将在本节中学习的那样，您应该始终考虑一个明确的令牌过期和撤销策略。

根据应用程序如何从 Keycloak 请求令牌，它们将获得一组令牌：

• ID 令牌

• 访问令牌

• 刷新令牌

正如您在前几章中学到的那样，根据客户端使用的授权类型，Keycloak 可能会颁发所有这些令牌或仅颁发其中的子集。每个令牌都有自己的生命周期。与刷新令牌（我们稍后将介绍）不同，ID 令牌和访问令牌具有相同的生命周期。这两个令牌都是短期的，通常由令牌存储不是最安全的公共客户端（例如，单页应用程序）使用。对于访问令牌，它经常通过网络发送，以便从资源服务器访问受保护的资源，并且容易受到拦截。其生命周期和有效性是减少泄露或撤销时影响的关键因素。

另一方面，刷新令牌的生命周期较长，其有效性取决于为用户和客户端会话设置的生命周期。此特性使 ID 令牌和访问令牌的生命周期较短成为可能，并且能够在这些令牌过期时刷新这些令牌。由于寿命更长，刷新令牌是攻击者的完美目标，他们还需要明确的过期和撤销策略。

正如您将在第 14 章 保护 Keycloak 和应用程序中看到的那样，您可以使用额外的安全层来保护令牌在泄漏时不被滥用，例如密钥轮换。然而，代币的生命周期对于确定客户端及其行为的整体安全性至关重要。

在本节中，简要介绍了有关令牌的一些基本概念，例如令牌的生命周期和有效性，以及它们如何影响应用程序的整体安全性。

在下一主题中，您将了解如何管理 Token 的生命周期。

管理 ID 令牌和访问令牌的生命周期

Keycloak 允许你像 sessions 一样设置 token 的生命周期。为此，请在 Realm Settings 页面上单击 Tokens 选项卡。在 Tokens 选项卡上，您应该能够限制上一主题中提到的所有三个令牌的生命周期，并可以定义刷新令牌的特定设置。

对于 ID 令牌和访问令牌，可以通过将 Access Token Lifespan （访问令牌生命周期） 设置更改为所需的任何值来设置其生命周期。

默认情况下，Keycloak 将这些令牌的生命周期设置为仅 5 分钟：

图 12.8：设置 ID 令牌和访问令牌生命周期

这个名字很令人困惑，但在幕后，Keycloak 使用 Access Token Lifespan 设置来计算 ID 令牌的生命周期。

Keycloak 还允许您基于每个客户端覆盖访问令牌生命周期。为此，请导航到客户端的详细信息页面，然后单击 Advanced 选项卡：

图 12.9：基于每个客户端覆盖 ID 令牌和访问令牌生命周期

在 Advanced Settings（高级设置）中，设置 Access Token Lifespan（访问令牌生命周期）以覆盖特定客户端的 ID 令牌和访问令牌的生命周期。

您设置的值应尽可能短，以减少令牌泄漏时的影响，从而强制客户端刷新其令牌。但是，太短的值也可能影响应用程序和 Keycloak 本身的性能，因为您将有更频繁的刷新令牌请求。对于大多数使用案例来说，默认值应该足够了，但您可以根据需要调整该值。

此设置对于访问令牌尤其重要，因为根据 RFC 6750–Bearer Token使用情况，它们经常作为访问后端服务（例如资源服务器）的Bearer Token通过网络传输。

如前所述，Keycloak 颁发的令牌基于 JWT 格式，这使得应用程序无需使用 Keycloak 的令牌内省端点对令牌进行额外的往返内省即可验证令牌，而是通过验证令牌签名和一些与生命周期相关的标准声明来实现。因此，根据你的安全要求，你可能无法容忍令牌在其生命周期内，但刷新令牌不再由 Keycloak 中的活动会话支持的情况。在这种情况下，为了关键操作的安全性，你可能愿意接受使用令牌内省端点带来的额外开销。

在这里，生存期也对用户体验和客户端的复杂性有直接影响。短寿命令牌通常与长寿命刷新令牌一起使用，以避免用户在令牌刷新期间最终重新进行身份验证。不过，由于需要处理刷新令牌的额外逻辑，使用刷新令牌的客户端实现起来更为复杂。另一方面，长寿命令牌通过消除频繁刷新的需要来帮助简化客户端，但是如果令牌发生泄漏，则会带来额外的风险。由您来找到适合您需求的正确平衡。

在本主题中，您了解了如何设置 ID 和访问令牌的生命周期。您了解了作为最佳实践，生命周期应尽可能短，以及短期令牌、刷新令牌、客户端复杂性、安全性和性能之间的相关性。最后，您了解了令牌的有效性可能与其会话状态不同步，以及如何通过使用令牌自省终端节点而不是执行令牌的本地验证来避免这种情况。

在下一主题中，您将了解如何管理刷新令牌的生命周期。

管理刷新令牌的生命周期

刷新令牌的生命周期由您在上一节中了解的空闲超时定义，用于分别设置用户会话和客户端会话的生命周期。此处相同的规则适用于其最长生存期，因此它们仅在您为用户和客户端会话设置的最长时间内有效。

首先，刷新令牌的生命周期是根据为客户端会话设置的时间计算的，方法是在领域级别设置 Client Session Idle （客户端会话空闲） 设置，或者基于每个客户端覆盖相同的设置。如果没有为客户端会话明确设置生命周期，则 Keycloak 将通过 SSO 会话空闲设置回退到您为用户会话设置的值。

要按客户端覆盖刷新令牌生命周期，请导航到客户端的详细信息页面，然后单击 Advanced 选项卡：

图 12.10：基于每个客户端覆盖刷新令牌生命周期

在 Advanced Settings （高级设置） 中，您可以通过设置 Client Session Max （客户端会话最大值） 和 Client Session Idle （客户端会话空闲） 设置来覆盖刷新令牌生命周期。请注意，默认情况下， Keycloak 不会在 Client 端级别为这些设置定义显式值，因此会使用在领域级别设置的值隐式设置它们，如上一节所述。

对于刷新令牌，应考虑以下事项：

• 在使用特定的授权授权类型（例如授权代码授权类型）对 Keycloak 中的用户进行身份验证后，刷新令牌始终绑定到客户端会话。

• 如果刷新令牌所绑定的用户和客户端会话尚未过期，则刷新令牌被视为有效。

• 仅当其各自的客户端会话仍处于活动状态时，客户端才应能够使用刷新令牌来获取新令牌。

通过考虑这三个注意事项，您应该能够意识到刷新令牌对于获取短期 ID 令牌和访问令牌的重要性，以及它们对应用程序的整体安全性有多重要，因为允许您基于每个客户端定义更严格的令牌生命周期策略。

刷新令牌的生命周期可以根据客户端能够安全保存令牌的程度进行调整。例如，一个保密的客户端可以有更长寿命的刷新令牌，而对于公共客户端，你可能希望有一个更短的时间窗口。

但请注意，一旦刷新令牌过期，用户将被迫重新向客户端进行身份验证，因此，如果使用浏览器，则会影响用户体验。

可能发生的最糟糕的情况之一是刷新令牌泄露。这将使攻击者能够从 Keycloak 获取令牌，并通过模拟颁发令牌的客户端来访问应用程序。当这种情况发生时，您可以设置不同的障碍来避免或减少影响。其中之一是刷新 Token 轮换。

在本主题中，您了解了如何管理 “刷新令牌” 生命周期及其对启用短期令牌和应用程序整体安全性的重要性。

在下一节中，我们将了解如何启用刷新令牌轮换以防止攻击者重复使用刷新令牌。

启用刷新 Token 轮换

作为刷新令牌泄露时的保护措施，Keycloak 允许您启用刷新令牌轮换。

刷新令牌轮换是一种策略，当合法客户端发出刷新令牌请求时，在颁发新令牌之前使刷新令牌失效，从而减少刷新令牌泄露的影响。启用后，轮换有助于快速识别刷新令牌何时泄露，并强制攻击者或合法客户端重新进行身份验证以获取一组新的令牌，包括新的有效刷新令牌。考虑到只有合法客户端才能向 Token 终端节点进行身份验证，因此只有它才能获取新的刷新令牌。

要启用刷新令牌轮换，请导航到 Realm Settings 页面上的 Tokens 选项卡，然后启用 Revoke Refresh Token 设置：

图 12.11：启用刷新令牌轮换

通过启用该设置，您将获得一个额外的 Refresh Token Max Reuse （刷新令牌最大重用） 设置，以定义客户端可以使用刷新令牌的次数，直到颁发新的刷新令牌，从而使以前的刷新令牌失效。

默认情况下，Refresh Token Max Reuse （刷新令牌最大重用） 设置设置为 0，这实际上意味着刷新令牌只能使用一次。如果客户端尝试重用相同的刷新令牌，Keycloak 将拒绝请求并强制客户端重新验证用户。例如，如果将值增加 1，则允许客户端仅使用相同的刷新令牌两次。

在实践中，刷新令牌轮换通常是在刷新令牌泄露时减少攻击面的良好做法。快速识别何时发生这种情况并对可能的漏洞做出反应也很有用。但是，这并不是您应该考虑的唯一安全措施，尤其是在与公共客户端打交道时。

公共客户端本质上是不安全的，因为它们不需要提供任何凭证来对令牌端点进行身份验证。因此，您应该考虑使用双向 TLS 客户端身份验证来强制使用发件人约束的令牌，其中客户端证书用于将令牌绑定到为其颁发令牌的客户端，从而防止攻击者在将刷新令牌提供给令牌终端节点时使用可能泄露的刷新令牌。有关更多详细信息，请查看 第 14 章 保护 Keycloak 和应用程序。

在下一主题中，您将了解如何撤销令牌，以便在不再需要令牌时简单地使令牌过期，或者作为对可能的漏洞的反应。

撤销令牌

Keycloak 允许您使用不同的方法撤销令牌。正如您在上一节 管理会话中学到的那样，令牌与会话绑定，当会话过期时，Keycloak 不再认为令牌有效。

无论用户和客户端如何，全局使令牌失效的最简单方法之一是使用 not-before-revocation 策略强制令牌根据设定的时间过期。

正如你在上一节中也了解到的，Keycloak 允许你通过点击左侧窗格中的 “Sessions” 项来管理领域中的活动会话。当在 “Sessions” 页面上时，你可以从 “Action” 选择框中点击 “Revocation” 操作来撤销在给定时间之前创建的令牌。

图 12.12：使用基于时间的吊销策略使会话过期

通过单击 Set to now 按钮，Keycloak 将自动使用当前时间填充 Not before 字段，并更新领域设置，以便在设置时间之前创建令牌时失败令牌验证。

请注意，使用 not-before 策略吊销令牌时，应用程序不会立即收到吊销状态的通知。

Keycloak 还允许你通过使基础会话（用户或客户端会话）过期，或者使用根据 RFC 7009 定义的撤销端点来撤销令牌。

通过使用会话过期撤销令牌，管理员应该能够利用您在上一节管理会话中学到的知识，自动使与会话关联的任何令牌失效。

另一方面，Keycloak 还允许客户端使用基于 RFC 7009 的特定端点（令牌撤销端点）撤销其令牌。通过使用这种方法，客户端可以帮助 Keycloak 跟踪未使用的令牌，减少令牌容易泄漏的时间，并清理与它们相关的任何数据以节省内存和 CPU 资源。有关如何使用令牌吊销终端节点吊销令牌的更多详细信息，请查看 https://www.keycloak.org/docs/latest/server_admin/#_oidc-endpoints 中的文档。

除 not-before 吊销策略外，所有其他方法都意味着通过使用令牌吊销终端节点时使领域中的所有活动会话过期或仅客户端会话来使用户和客户端会话过期。not-before 策略仅影响令牌的验证方式；它们的相应会话将保持活动状态，直到它们最终过期。

在本节中，您了解了令牌管理的一些关键方面以及令牌如何与会话管理相关联。首先，您了解了有关令牌生命周期的关键概念和注意事项，以及用于配置令牌生命周期的不同设置。然后，您了解了刷新令牌如何启用短期访问令牌，以及它们对应用程序的整体安全性和性能的重要性。最后，您了解了刷新令牌轮换如何帮助减少刷新令牌泄露时的攻击面，以及撤销令牌的不同方法。

总结

在本章中，您了解了令牌和会话管理的一些关键方面。通过利用您从本章中学到的知识，您应该能够为会话过期和令牌吊销定义明确的策略，并考虑它们对安全性、用户体验以及应用程序和 Keycloak 性能的影响。

在下一章中，您将了解 Keycloak 的主要方面之一 – 可扩展性 – 以及如何扩展它以适应和满足未满足的需求。

问题

1. Keycloak 是否将会话存储在数据库中？

2. 用户会话和客户端会话有什么区别？

3. 您如何主动撤销令牌和使会话过期？

4. 应用程序如何验证令牌？

5. 访问令牌生命周期对客户端有何影响？

延伸阅读

有关本章中涵盖的主题的更多信息，请参阅以下链接：

• Keycloak 用户和会话管理：https://www.keycloak.org/docs/latest/server_admin/#user-session-management
• 相互 TLS 客户端身份验证：https://www.keycloak.org/docs/latest/server_admin/#advanced-settings
• 令牌撤销端点：https://tools.ietf.org/html/rfc7009
• Keycloak 威胁模型缓解措施：https://www.keycloak.org/docs/latest/server_admin/#compromised-access-and-refresh-tokens
• OAuth 2.0 威胁模型和安全注意事项：https://tools.ietf.org/html/rfc6819
• OAuth 2.0 安全最佳当前实践：https://www.keycloak.org/docs/latest/server_admin/#_account-service。