基于 JWT + Refresh Token 的用户认证实践.docxVIP

基于 JWT + Refresh Token 的用户认证明践 2021-02-06 HTTP 是一个无形态的协议，一次恳求结束后，下次在发送服务器就不晓得这个恳求是谁发来的了（同一个 IP 不代表同一个用户），在 Web 应用中，用户的认证和鉴权是格外重要的一环，实践中有多种可用方案，并且各有千秋。 - 基于 Session 的会话管理 - 在 Web 应用进展的初期，大部分接受基于 Session 的会话管理方式，规律如下。 · 客户端使用用户名密码进行认证 ·?服务端生成并存储 Session，将 SessionID 通过 Cookie 前往给客户端 ·?客户端访问需要认证的接口时在 Cookie 中携带 SessionID ·?服务端通过 SessionID 查找 Session 并进行鉴权，前往给客户端需要的数据 基于 Session 的方式存在多种问题。 ·?服务端需要存储 Session，并且由于 Session 需要经常快速查找，通常存储在内存或内存数据库中，同时在线用户较多时需要占用大量的服务器资源。 ·?当需要扩展时，创建 Session 的服务器可能不是验证 Session 的服务器，所以还需要将全部 Session 单独存储并共享。 ·?由于客户端使用 Cookie 存储 SessionID，在跨域场景下需要进行兼容性处理，同时这种方式也难以防备 CSRF 攻击。 - 基于 Token 的会话管理 - 鉴于基于 Session 的会话管理方式存在上述多个缺点，无形态的基于 Token 的会话管理方式诞生了，所谓无形态，就是服务端不再存储信息，甚至是不再存储 Session，规律如下。 ·?客户端使用用户名密码进行认证 ·?服务端验证用户名密码，通过后生成 Token 前往给客户端 ·?客户端保存 Token，访问需要认证的接口时在 URL 参数或 HTTP Header 中加入 Token ·?服务端通过解码 Token 进行鉴权，前往给客户端需要的数据 基于 Token 的会话管理方式有效处理了基于 Session 的会话管理方式带来的问题。 ·?服务端不需要存储和用户鉴权有关的信息，鉴权信息会被加密到 Token 中，服务端只需要读取 Token 中包含的鉴权信息即可 ·?避开了共享 Session 导致的不易扩展问题 ·?不需要依靠 Cookie，有效避开 Cookie 带来的 CSRF 攻击问题 ·?使用 CORS 可以快速处理跨域问题 - JWT 引见 - JWT 是 JSON Web Token 的缩写，JWT 本身没有定义任何技术实现，它只是定义了一种基于 Token 的会话管理的规章，涵盖 Token 需要包含的标准内容和 Token 的生成过程。 一个 JWT Token 长这样。 eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJleHAiOjE1NDQ1MTE3NDMsImp0aSI6IjYxYmVmNjkyLTE4M2ItNGYxYy1hZjE1LWUwMDM0MTczNzkxOSJ9.CZzB2-JI1oPRFxNMaoFz9-9cKGTYVXkOC2INMoEYNNA 认真辨别会发觉它由 A.B.C 三部分组成，这三部分依次是头部（Header）、负载（Payload）、签名（Signature），头部和负载以 JSON 方式存在，这就是 JWT 中的 JSON，三部分的内容都分别单独经过了 Base64 编码，以 . 拼接成一个 JWT Token。 JWT 的 Header 中存储了所使用的加密算法和 Token 类型。 { alg: HS256, typ: JWT } Payload 是负载，JWT 规范规定了一些字段，并推举使用，开发者也可以本人指定字段和内容，例如下面的内容。 { username: yage, email: sa@, role: user, exp: 1544602234 } 需要留意的是，Payload的内容只经过了 Base64 编码，对客户端来说当于明文存储，所以不要放置敏感信息。 Signature 部分用来验证 JWT Token 能否被篡改，所以这部分会使用一个 Secret 将前两部分加密，规律如下。 HMACSHA256(base64UrlEncode(header)?+?.?+?base64UrlEncode(payload),?secret) - JWT 优势 问题 -? JWT 拥有基于 Token 的会话管理方式所拥有的一切优势，不依靠 Cookie，使得其可以防止 CSRF 攻击，也能在禁用 Cookie 的扫瞄器环境中正常运转。 而 JWT 的最大优势是