当前位置：首页 > news >正文

Token 设计

news 来源：原创 2024/9/21 2:36:52

一什么是Token？

Token（令牌）在现代软件开发中非常常见，尤其是在涉及认证和授权的系统中。以下是 Token 的主要用处和应用场景：

1. 身份验证 (Authentication)

Token 常用于验证用户的身份，确认用户是否已经通过身份验证。例如：

用户在登录时输入用户名和密码，服务器验证成功后生成一个 Token 作为用户的身份凭证。
之后，用户的每个请求都会携带这个 Token，服务器可以根据这个 Token 确认用户身份，而不需要每次都重新验证用户名和密码。

2. 授权 (Authorization)

除了身份验证，Token 还常用于确定用户是否有权限访问特定的资源或执行某些操作。例如：

基于角色的访问控制（RBAC）：Token 中可以包含用户的角色或权限信息，服务器可以根据这些信息决定是否允许用户执行某些操作。
访问特定 API 或微服务：在分布式系统中，Token 可以在服务之间传递，用于授权和安全通信。

3. 无状态 (Stateless) 认证机制

Token（尤其是 JWT, JSON Web Token）常用于无状态的认证机制：

传统的会话认证（如 Cookie + Session）需要在服务器保存每个用户的会话状态。而使用 Token（如 JWT），所有的用户状态信息都可以编码在 Token 内，服务器只需验证 Token 的有效性即可，极大降低了服务器的负担。
这使得系统更易于扩展（Scalable），因为服务器无需保存用户的会话信息，可以轻松实现负载均衡和无状态的微服务架构。

4. 跨平台和跨设备访问

Token 适合用于各种平台和设备的认证场景，比如：

移动应用：Token 可以安全地在移动设备上存储，并在每次请求时附带发送。
单页面应用 (SPA)：前端应用通常在用户登录后获取 Token，并存储在浏览器中（如 LocalStorage 或 SessionStorage）用于后续的 API 调用。

5. API 安全访问

在开放或公开的 API 中，Token 是常见的安全手段之一：

使用 OAuth 标准的 Access Token，第三方应用可以安全地访问用户授权的数据。
开发者可以通过获取的 Token 访问特定 API，Token 限定了访问的权限和范围。

6. 临时访问权限

在一些场景中，Token 可以用作临时访问凭证，例如：

临时文件下载：生成一个短期有效的 Token，允许用户在有限时间内访问文件或资源。
重置密码或邮箱验证链接：链接中包含的 Token 通常有时间限制，确保安全性。

7. 安全性

Token 通过以下方式提高安全性：

加密和签名：Token 可以使用加密或签名技术防止篡改。即使 Token 被拦截，未经授权的用户也无法轻易伪造或修改 Token。
短期有效：Token 的有效期通常较短，过期后即失效，减少了长期 Token 泄露带来的风险。
刷新机制：一些系统采用 Refresh Token 机制，Access Token 短期有效，过期后可以通过较长期的 Refresh Token 获取新的 Access Token。

8. 无缝集成和第三方应用

在 OAuth 等协议中，Token 被广泛用于授权第三方应用访问资源：

用户可以授权某个应用访问他们在其他平台上的数据，而无需暴露自己的登录凭证。
例如，允许一个社交媒体应用获取用户的联系人信息。

典型的 Token 类型：

JWT（JSON Web Token）：常用于无状态的 Web 应用和 API 认证。
OAuth Access Token：广泛用于第三方应用授权和 API 访问。
Refresh Token：用于在 Access Token 过期后生成新的 Access Token，减少频繁登录的需求。

总之Token 是一种灵活且广泛使用的认证和授权机制，尤其在现代的分布式系统、微服务架构和前后端分离的应用中。通过 Token，系统可以实现无状态、跨平台、安全且高效的用户身份管理和资源访问控制。

二 token 设计

Token 设计涉及到多个方面，包括其结构、生成方式、安全性、生命周期管理等。一个好的 Token 设计需要兼顾安全性、性能和可扩展性。以下是设计 Token 时需要考虑的几个关键要素：

1. Token 的类型

JWT (JSON Web Token)：这是最常见的 Token 类型，采用 JSON 格式，可以包含用户信息、权限等，此类Token是一串比较长的加密信息，现在开发过程中比较少用。
普通 Token：通常是随机生成的字符串，只有服务器知道它的含义。使用这种 Token 时，所有信息都保存在服务器端，客户端仅持有一个引用 ID，长度基本是固定，很多时候直接使用UUID生成，现实开发过程中比较常用，特别是API接口调用基本都用这种类型。

2. Token 的内容设计

最小化数据：尽量减少存储在 Token 中的数据，只包含必要的信息。例如用户 ID、角色、权限、Token 的过期时间等。
标准化字段：如果使用 JWT，可以利用标准的字段，如 iss（签发者）、exp（过期时间）、sub（主题，如用户 ID）、aud（受众）。
自定义字段：可以添加自定义字段用于业务需求，如 role、scope 等。

3. Token 的生命周期管理

有效期 (Expiration Time, exp)：Token 应该设置合理的有效期，以减少安全风险。一般的 Access Token 有效期较短，如 15 分钟或 2 小时。
Refresh Token 机制：对于长时间保持登录状态的应用，可以使用 Refresh Token。当 Access Token 过期时，通过 Refresh Token 获取新的 Access Token，避免频繁要求用户重新登录。
Token 的自动失效：设计 Token 时，要考虑如何强制失效特定 Token，比如用户主动登出、修改密码后使旧 Token 失效。

4. Token 的存储

浏览器客户端存储：Token 通常存储在浏览器的 LocalStorage、SessionStorage 或 Cookie 中。使用 Cookie 时，应设置 HttpOnly 和 Secure 属性以提高安全性。

注意：避免 XSS 和 CSRF 攻击：如果 Token 存储在 LocalStorage 或 SessionStorage，应用需要防范 XSS 攻击；如果存储在 Cookie，需要防范 CSRF 攻击。

服务端存储：Token 通常存储在内存或内存数据库，如Redis数据库，很方便设计到期时间，另外保存副本到数据库。

5. Token 的传输

使用 HTTPS：Token 传输时都应该使用 HTTPS 以防止被中间人攻击拦截。
Bearer Token：在 HTTP 请求中，Token 通常作为 Authorization 头的一部分发送，格式为：Authorization: Bearer <token>。

6. 内容类型的 Token 安全设计

签名和加密：使用强健的加密和签名算法，例如 HMAC-SHA256、RSA-SHA256 等。
防重放攻击：考虑加入唯一标识符（如 jti 字段）和时间戳来防止重放攻击。
权限控制：Token 中包含的权限信息应与服务器进行严格验证，以确保用户只访问其有权访问的资源。

7. Token 的管理与撤销

黑名单机制：可以通过维护一个 Token 黑名单或撤销列表，来强制失效某些 Token，特别是在用户登出或发生异常时。
状态存储：对于不透明的 Token，服务器可以将其状态存储在数据库或缓存中，允许随时撤销或更新。

8. Token 的兼容性和扩展性

多平台支持：确保 Token 在不同平台（Web、移动、桌面）上能够兼容，通常选择标准的 JWT 是一个好方案。
灵活的权限模型：设计 Token 时，可以考虑使用权限范围（Scope）或角色（Role）模型，以支持多种业务场景。

9. Token 刷新策略

设计 Refresh Token 时，可以使其有效期较长，例如几天到几周，但确保在适当时机刷新，且 Refresh Token 一旦被使用，旧的 Token 应该失效。

三 token 重点（有效期时间计算）

1 token 有效期时间是设计和理解：

Token 的有效期，很多大厂有关 Token 的设计的有效期像都被设置 2 小时。有效期的计算实际就是指从调用接口获取 Token 的时间开始算，而不是指服务器每 2 小时统一更新一次 Token（注意：请不要理解成提供token每两小时更新一次）。

Token 有效期从生成时开始计时：当你通过认证接口获取到 Token 时，服务器会记录生成 Token 的时间，并从这一时刻开始计算有效期。如果有效期是 2 小时，那么这个 Token 将在获取后的 2 小时内有效。
每次获取的 Token 是独立的：每次调用获取 Token 的接口时，都会返回一个新的 Token，并从生成时刻起重新计时其有效期。这意味着不同用户或不同请求获取的 Token 的有效期开始时间是不同的。
Token 到期后需要重新获取：在 2 小时有效期过后，旧的 Token 会失效，客户端需要再次调用接口获取一个新的 Token。

总的来说，文档中提到的 2 小时有效期，是从你成功获取 Token 的时间开始计算的，而不是服务器在固定的时间点批量更新 Token。作为token服务端提供给客户使用时，一定要设计正确的有效期，比如Token设计成服务器本地有效期时（不管客户端是否拿取，服务器内每2 小时更新一个token），可能会造成客户端拿到了token还没有达到设计文档要求的2个小时就失效错误，如果碰巧，还有可能碰刚好客户端拿到Token，Token服务器更新Token,客户端就失效。