一 什么是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,客户端就失效。
开发设计时,还可以参考国内大厂的一些有关token的Api文档设计:
1 蚂蚁集团-支付宝有token的api文档设计如下图:
2 微信有关token 的api文档图如下:
3 南方电网中电联协议有关token的文档
还给了自定义时长,自由度非常大,开发时就要注意把握设计合适的时长了。