认证服务 ​

认证策略分为三类：

• HTTP Basic 认证
• 基于Session的认证
• 基于Token的认证

HTTP Basic 认证 ​

HTTP Basic 认证 实现简单，但功能弱：

• 不安全。后续任何同源请求，浏览器都会自动为请求头带上缓存的Authorization标头，其中包含用户的敏感信息如密码
• 不能跨子域
• 登录过期取决于浏览器缓存过期

基于Session的认证 ​

Session认证 实现较难，因为需要服务端存储 Session ID，带来管理 Session ID 的问题。例如随服务端规模的增长，需要共享 Session ID。 得益于服务端存储和管理登录状态，功能强：

• 安全。Session ID 不含用户信息，泄露影响小
• 任意位置存储，并且存储字符大小可以做到相比其他方案最小
• 登录过期可控，并可以实现登录“互踢”功能

github.com 使用的就是Session认证

基于Token的认证 ​

Token认证 实现较简单，不需要服务端存储，但需要制定Token加解密规则。功能较强：

• 安全。Token是服务端加密过的字符串，泄露影响小
• 任意位置存储，但存储字符大小相比其他方案最大
• 登录过期可定义，例如在 Token 中记录登录日期，那么可以在定义日期后自动过期

JWT（JSON Web Token） ​

由于 Token 认证在三类认证策略中经济实惠，成为最受欢迎的方案，那么制定Token加解密规则就成为了开发者经常思考的问题。

JWT是一种Token认证形式，基于开放标准（RFC 7519）。

举例一个JWT的结构

header.payload.signatrue

或者换种表意

description.data.secret

它为Token添加了可读性，并通过加密签名的方式为Token防篡改。

因此，即使JWT上除签名外，所有内容都不是敏感信息，并且信息未加密可读取，它仍然是一个有效的Token，可以作为登录用的凭据，此时签名就承担了Token的认证作用。

工具库 ​

有标准就可以封装为工具库，如npm包 jsonwebtoken。

登录作为普遍的业务场景，每家公司都会有自己的实现方式，一般只需要了解原理。如需实践，可以参考开源的npm库 passport。