参考 理解 OAuth 2.0
JSON Web Token 入门教程
知乎 想全面理解JWT？一文足矣！
这三个相互连接且是由大到小的一种关系,OAuth规定授权流程,Token为其中一环的一个信息载体,具体的一种实现方式由JWT规定
为什么 有 session， 有些接口是要登陆访问的，那总不能每次都输密码，后台验证把，这也太不安全了，参数还多了不少，每次验证还要查数据库，傻逼了，于是 session 就是记录验证密码的状态，提高接口访问效率。为啥有些 用 JWT 了，看下面的介绍就明白了。
1、Session：每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以便用户下次请求的鉴别，通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大
2、扩展性：用户认证之后，服务端做认证记录，如果认证的记录被保存在内存的话，这意味着用户下次请求还必须要请求在这台服务器上，这样才能拿到授权的资源，这样在分布式的应用上，响应的限制了负载均衡器的能力，也意味着限制了应用的扩展性
3、CSRF：因为是基于cookie来进行用户识别的，cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击
oauth > token > twt
oauth
这个东西 就是为了鉴权设计的，而且是针对第三方授权，比如你需要 wps 打开百度的云的文档，那就要百度云登陆授权。一个 老思路是，直接输入账号密码，但是这样wps 就有可能保存密码，非常的不安全。万一你登陆了很多个第三方，密码泄露是很容易的， 于是 百度云就用现在流行的授权方式 —— oauth （现在基本是 OAuth 2.0）
Oauth 就是想让第三方安全的获取授权。
Oauth 实现的思路
提供一个中间授权层， 用户不直接登陆服务层，而是用令牌登陆授权层， 令牌里面有权限和过期时间，服务资源根据权限来提供 资源的访问
这个图是真经典
a 客户端请求可以授权， 并拿到授权码
c 客户端使用授权码 请求拿到token
d 使用 token 请求拿到资源
( 我把 三个部分取资源 简化了一下)
-
那第一步，怎么拿到申请 token 的授权码？
你肯定见过这样的场景，就是点击 微信登陆，然后你点击弹框的确认，随后便登陆成功第三方客户端了。
授权码就是在 你点击确认的时候 你的已经登陆的微信客户端生成发放的，第三方客户端 拿到这个授权码去请求 token -
从授权码到 token
客户端向服务端 请求 token, 包含以下参数：
a) grant_type：表示使用的授权模式，必选项，此处的值固为"authorization_code"code：表示上一步获得的授权码，必选项。
b ) redirect_uri：表示重定向URI，必选项，且必须与A步骤中的该参数值保持一致
c ) client_id：表示客户端ID，必选项
授权服务响应
a) access_token：表示访问令牌，必选项
b) token_type：表示令牌类型，该值大小写不敏感，必选项，可以是bearer类型或mac类型
c) expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间
d) refresh_token：表示更新令牌，用来获取下一次的访问令牌，可选项
e) scope：表示权限范围，如果与客户端申请的范围一致，此项可省略
除了上面的 授权码模式，还有一个是 用户名密码模式
提供用户名密码给第三方客户端。通常是建立在高度信任第三方客户端的情况下。
A） grant_type：表示授权类型，此处的值固定为"password"，必选项
B) username：表示用户名，必选项。
C) password：表示用户的密码，必选项。
D) scope：表示权限范围，可选项。
由此可见的是： Oauth 包含了很多的内容，其中是包含 token 的获取的。
jwt 实现思路
jwt 是为了跨域，分布式 的认证解决方案，关于 神马情况下用 jwt ,本文开头已经说了一下
为了加深印象，那我们再来复习一下，单机的 基于 session cookie 的认证方式
a) 用户发送用户名密码
b) 服务端验证密码，通过后就生成一个 session ( 包含用户信息，过期时间等，通常保存在 内存里), 并返回一个 session_id ，用于检索 session 用的。
c) 客户端保存 session_id 到 cookie ，以后每次请求都直接 带上 session_id ， 后端会自动验证认证状态。
可以看到 session 是基于 cookie , 跨域用不了这个方法 ，另外就是集群 内存不共享的情况下，必须持久化到数据库等，才能（用户太多，都放在内存不合理）
关于 跨域
（ 跨域 就是 前端 ajax (同源限制) 请求接口的问题，前端访问的写的端口 协议等，和你请求的 api 不一致， 解决可以 后端或者 nginx 添加响应头 Access-Control-Allow-Origin 或者 jsonp 等）
jwt 就不一样了，他不保存在 服务端，而是保存到客户端（服务器变成无状态了）
假设保存在 客户端的信息如下：
{
"姓名": "张三",
"角色": "管理员",
"到期时间": "2018年7月1日0点0分"
}
每次请求都携带这个信息，那不就直接实现认证了码，这只是举个例子，实际肯定不能这样直接明文获取，防止用户随意篡改。
jwt 结构
实际的 就是 一个 a.b.c 的字符串
Header.Payload.Signature
- Header
是描述 jwt 的元数据 编码为 Base64URL 字符串
{
"alg": "HS256", // 签名算法
"typ": "JWT" // 签名类型， jwt 就是 JWT
}
- Payload
实际需要的 数据（ 签名时间，过期时间，等等） Base64URL编码
这几个是官方的数据：
iss (issuer)：签发人
exp (expiration time)：过期时间
sub (subject)：主题
aud (audience)：受众
nbf (Not Before)：生效时间
iat (Issued At)：签发时间
jti (JWT ID)：编号
此外你也可以添加自己需要的字段
上面的 Base64URL 编码 近似 base64 ， 只因为 某些 使用 token的方式为直接放到了 url， api.example.com/?token=xxx， url 不能出现 64 个字符中的 + / 和= （和 url 的格式冲突，= 被省略、+替换成-，/替换成_ ）
- Signature
为了防止篡改 前两个数据，特地弄出了 这个 来做校验（你可能会问，直接解密 Signature 拿到数据不就行了，不行， Signature 解密签名得到哈希值， 然后对比 Payload 和 Header 的哈希值 ， 因此校验一致的话，就用 前两个base64 的解密 数据了）
问：为啥 不用 RSA 等加密直接解密 Payload
答： 加密解密过程比较慢（如果 Payload 比较大， 那就不划算了，就有这样一句话，哈希的时间，远比加密时间快得多 ）
如果我们得到的哈希结果和JWT第三部分的签名值是一致的
Signature 部分是对前两部分的签名，防止数据篡改
HMACSHA256(
base64UrlEncode(header) + "." +
base64UrlEncode(payload),
secret)
secret 为服务器的 密匙，用于混淆签名（ 就像我用 aes 校验一样，本地密匙，加上 需要加密的字符，这样即使请求端，知道 是aes 加密算法，他不知道密匙，后台解密也是失败不通过的， 哈哈）
说了jwt 的生成，那么具体使用怎么做呢？
a) 客户端提交 用户名和密码 ， 服务端 验证密码，并生成 用户信息的数据 Payload 和 Header
b) 密匙加密 Header 和 Payload 生成签名发送给客户端使用
c) 客户端收到请求后， 可以保存在cookie ,然后每次请求自动发送（跨域不行）
或者 放在 请求头 , 或者 直接放在 post 请求里面
Authorization: Bearer <token>
这几个方法，一般后端的校验都会考虑到，是能娶到值的。
使用 JWT 需要注意的地方：
-
你可以对 jWT 再次加密，确保万一 Header 和 Payload 保存了重要数据，不让客户端看到
-
也可以把需要交换的数据 ，放到 jWT 里面，减少查询数据库的次数（具体的需要服务和客户端保持一致）
-
尽量 减少token 有效期，因为比如你 token 设置了 一天，那如果想更新 token 里面的字段值，只能等下次失效才能更新了。
-
减少盗用，尽量 https 传输 token
网友评论