okta 2025-01-23
基于令牌的身份验证是一种协议，允许用户验证其身份，并在验证成功后获得一个唯一的访问令牌（access token）。在令牌有效期内，用户可以使用该令牌访问为其颁发的网站、应用程序或受保护资源，而无需每次返回同一页面、应用或资源时都重新输入凭据。
身份验证令牌的工作原理类似于一张盖章的票券。只要令牌仍然有效，用户就保有访问权限。一旦用户注销或退出应用程序，该令牌即被作废。
基于令牌的身份验证不同于传统的基于密码或服务器的身份验证方式。令牌提供了额外的安全层，管理员还能对每个操作和事务进行精细控制。
不过，使用令牌需要一定的编码知识。虽然大多数开发者能很快掌握相关技术，但仍存在一定的学习曲线。
下面我们将深入探讨，帮助你判断令牌是否适合你和你的组织。
身份验证令牌的发展简史
身份验证（Authentication）与授权（Authorization）是两个不同但相关的概念。在身份验证令牌出现之前，我们主要依赖密码和服务器。我们使用传统方法来确保正确的人在正确的时间访问正确的资源，但效果并不总是理想。
以密码为例，通常涉及以下步骤：
- 用户生成：用户创建一个由字母、数字和符号组成的组合。
- 记忆：用户必须将这个唯一组合记在脑中。
- 重复输入：每当需要访问某项资源时，用户都必须重新输入密码。
密码被盗非常普遍。事实上，早在 1962 年 就已记录了首例密码盗窃事件。人们难以记住所有密码，因此常采用以下“技巧”：
- 写下来：把密码写在纸上——这本身就是严重的安全隐患。
- 重复使用：在多个地方使用相同密码。一旦一个密码泄露，多个账户都会面临风险。
- 微调修改：在系统要求更新密码时，仅更改一个字母或数字。
此外，密码还需要服务器端的身份验证。每次用户登录时，服务器都会创建一条事务记录，从而增加内存负担。
而令牌身份验证则不同。
在令牌身份验证中，一个辅助服务会验证服务器请求。验证完成后，服务器会签发一个令牌并响应请求。
用户可能仍需记住一个密码，但令牌提供了一种更难被窃取或破解的访问方式。而且，会话记录不会占用服务器空间。
三种常见的身份验证令牌类型
所有身份验证令牌都能提供访问权限，但每种类型的工作方式略有不同。
以下是三种常见的身份验证令牌类型：
- 连接式令牌（Connected）：通过密钥、磁盘、U 盘或其他物理设备插入系统以获取访问权限。例如，如果你曾使用 USB 设备或智能卡登录系统，你就使用过连接式令牌。
- 非接触式令牌（Contactless）：设备无需插入，只需靠近服务器即可通信。例如，微软提出的“魔法戒指（magic ring）”就属于此类令牌。
- 离线式令牌（Disconnected）：设备即使不接触其他设备，也能通过远距离与服务器通信。例如，如果你曾用手机完成双因素身份验证（2FA），你就使用过这种令牌。
在这三种场景中，用户都必须先执行某些操作才能启动验证流程，比如输入密码或回答问题。但即使这些初步步骤全部完成，没有访问令牌，用户依然无法获得访问权限。
基于令牌的身份验证四步流程
使用基于令牌的身份验证系统后，访客只需验证一次凭据，随后即可获得一个令牌，在你设定的有效期内持续访问资源。
整个流程如下：
- 请求（Request）：用户请求访问服务器或受保护资源。这可能涉及密码登录，也可能涉及你指定的其他验证方式。
- 验证（Verification）：服务器确认该用户应具有访问权限。这可能包括检查用户名与密码是否匹配，或执行你定义的其他验证逻辑。
- 令牌签发（Tokens）：服务器与身份验证设备（如戒指、密钥、手机等）通信。验证成功后，服务器签发一个令牌并传递给用户。
- 存储（Storage）：令牌保存在用户的浏览器中，供后续操作使用。
当用户尝试访问服务器的其他部分时，令牌会再次与服务器通信。服务器根据令牌决定是否授予访问权限。
管理员可对令牌设置限制。例如，你可以签发一次性令牌（用户登出后立即失效），也可以设置令牌在指定时间后自动销毁。
JSON Web Token（JWT）：一种特殊的认证令牌
如今，大量用户通过移动应用和 Web 应用访问系统，开发者亟需一种适用于这些平台的安全身份验证方式。
为解决这一挑战，许多开发者在构建应用时选择使用 JSON Web Token（JWT）。
JWT 是一种开放标准，可用于在两个实体之间安全地传输信息。数据通过数字签名进行验证；若通过 HTTP 传输，还可使用加密保障数据安全。
JWT 包含三个核心组成部分：
- 头部（Header）：定义令牌类型及所使用的签名算法。
- 载荷（Payload）：包含令牌签发者、过期时间等声明信息。
- 签名（Signature）：用于验证消息在传输过程中未被篡改。
通过编码将这三部分组合起来，最终的 JWT 看起来类似如下格式：
xxxxx.yyyyy.zzzzz
不要被 JSON 代码吓到。这种格式在实体间传递数据时非常常见，网上也有大量教程。如果你对使用 JWT 感兴趣但尚未接触过 JSON，可以参考相关学习资源。
JWT 的优缺点
优点：
- 体积小：JWT 非常轻量，可在实体间快速传递。
- 易用性：几乎可在任何地方生成，且无需在你的服务器上进行验证。
- 精细控制：你可以精确指定用户可访问的内容、权限有效期以及可执行的操作。
缺点：
- 单密钥风险：JWT 依赖单一密钥。一旦密钥泄露，整个系统将面临风险。
- 复杂性：理解 JWT 并不容易。如果开发者缺乏对加密签名算法的深入理解，可能无意中引入安全漏洞。
- 功能限制：无法向所有客户端推送消息，也无法从服务器端集中管理客户端会话。
为什么你应该尝试使用授权令牌？
你可能认为当前的身份验证策略运行良好，那为何还要引入授权令牌？实际上，采用令牌能带来切实的好处。
授权令牌特别适用于以下场景的系统管理员：
- 频繁授予临时访问权限：用户群体随日期、时间或特殊事件波动，反复手动授/撤权限过于繁琐。例如，大学图书馆网站的管理员可能会从令牌方案中受益。
- 需要细粒度访问控制：你的服务器基于文档属性（而非用户属性）授予权限。密码机制无法实现如此精细的控制。例如，你运营一个在线期刊，希望用户只能阅读和评论某一篇特定文章，而不能访问其他内容——令牌可以实现这一点。
- 高价值目标，易受攻击：你的服务器存储高度敏感的数据，一旦泄露将对公司造成严重损害。仅靠密码不足以提供充分保护，而硬件令牌能显著提升安全性。
当然，还有更多使用场景。上述示例希望能激发你的灵感——思考得越多，越有可能发现令牌对你系统的价值。
身份验证令牌的最佳实践
身份验证令牌旨在增强你的安全策略并保护服务器安全。但若设计不当，它们反而可能成为漏洞。
你的身份验证令牌应做到以下几点：
- 私密性：用户不得共享令牌设备或在部门间传递。就像不应共享密码一样，也不应共享任何安全组件。
- 安全性：令牌与服务器之间的通信必须通过 HTTPS 加密，确保数据传输安全。
- 定期测试：定期对令牌系统进行安全测试，确保其正常运行。发现问题应立即修复。
- 选型恰当：根据具体用例选择合适的令牌类型。例如，JWT 并不适合用作会话令牌——它成本较高，且一旦被拦截，安全风险无法完全消除。务必为任务选择最合适的工具。
不要轻率决定是否采用身份验证令牌。务必做好调研，咨询同行，确保为你的公司做出最佳选择。