无状态和有状态架构

指的是应用程序的状态，即给定时间的条件或质量。在无状态身份验证中，不存储会话或用户，仅包含静态内容。这与有状态不同，有状态是动态内容。

无状态进程是一种孤立的资源，它不引用任何其他服务或与另一个系统的交互。它仅在代码的该部分中运行，不会从旧事务中引入信息，因为无状态身份验证不存储此类数据；每个操作都是从头开始完成。

状态身份验证允许信息多次使用，并基于先前事务的上下文执行。因此，在需要等待响应或预先存在的数据的应用程序中，无论是否存在于另一个系统或数据库中，都使用有状态。

无状态认证

无状态身份验证包含一种策略，在该策略中，用户在提供凭据后会收到访问令牌作为响应。该令牌已包含识别生成它的用户所需的所有信息，而无需不断查询颁发令牌的服务或数据库。

此令牌存储在客户端（浏览器），因此服务器只能通过确认有效负载和签名匹配来检查令牌的有效性。

无状态认证 JWT

JSON Web Token (JWT) 是具有 RFC-7519 中建立的标准的密钥，包含声明形式的实体，这些实体是独立的，无需调用服务器重新验证令牌。

是使用密钥以base64标准编码的字符串，如示例所示：

优点和缺点

优点：

• 服务器内存消耗低。
• 在可扩展性方面非常出色。
• 非常适合分布式应用程序，例如 API 和微服务。
• 在独立的应用程序中生成和分发令牌，不依赖第三方。
• 轻松解释和验证代币用户数据。

缺点：

• 访问控制困难。
• 无法随时轻易撤销令牌。
• 如果有人有权访问令牌，它可以促进恶意第三方的进入。
• 在令牌过期之前，会话无法更改。
• JWT 令牌更加复杂，在中心化应用程序（例如整体式应用程序）中可能变得不必要。

状态认证

常用于各种应用程序，尤其是那些不需要太多可扩展性的应用程序，有状态会话在应用程序的后端中创建，并将会话引用发送回相应的用户。每次用户发出请求时，应用程序的一部分都会生成令牌。从那时起，对于每个新请求，该令牌将再次发送到应用程序以重新验证访问权限。在这个模型中，如果用户数据发生任何变化，令牌可以很容易地被撤销。

这些是不透明的访问令牌，即专有格式的简单字符串，不包含与该令牌相关的任何标识符或用户数据。接收者需要调用创建令牌的服务器来验证它。

示例令牌：8c90e55a-e867-45d5-9e42-8fcbd9c30a74

此 ID 必须与拥有该令牌的用户一起存储在数据库中。

优点和缺点

优点：

• 集中实现逻辑。
• 简化访问管理和控制。
• 非常适合单体应用、MVC 应用程序和内部流程。
• 更安全地抵御恶意第三方。

缺点：

• 负责验证令牌的 API 中可能存在过载。
• 可扩展性方面失败。
• 在微服务之间分配身份验证的难度更大。
• 在分布式应用中，如果身份验证服务失败，则所有其他服务将变得不可用。
• 更高的实施复杂性。
• 与第三方系统集成难度较大。

何时使用每种方法？

何时使用 JWT 令牌和无状态身份验证

• 当需要更高的性能而不用担心 API 过载时。
• 当服务之间分布有多个通信时。
• 当需要识别哪个用户在不同服务中的系统中执行操作时。
• 当不打算保留用户的数据时，仅保留他们的初始注册。
• 如果需要生成对服务的外部访问。
• 如果有必要在对系统影响最小的情况下操纵执行特定操作的人员的数据。

何时使用不透明令牌和状态身份验证

• 如果需要对系统用户进行完全访问控制，主要是定义访问层次结构。
• 在集中式应用程序中，没有分布式服务，也没有与外部服务通信。

最终考虑因素：

• 在某些地方，例如“API 压力”，为了清楚起见，该术语可能会替换为“API 开销”。
• 如果目标受众需要更多上下文，“JWT 令牌”部分可以包含对 RFC-7519 中提到的“声明”内容的更详细解释。
• 在状态身份验证部分中，可以通过解释应用程序的哪个特定部分负责这一点来澄清“应用程序的一部分将生成令牌”这一短语。