鉴权
2020-04-16 11:09:37 0 举报AI智能生成
前端鉴权知识
作者其他创作
大纲/内容
session 认证
问题
服务端开销大:
每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，
通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。
扩展性有限:
用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，
这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，
这样在分布式的应用上，限制了负载均衡器的能力，这也意味着限制了应用的扩展能力。
CSRF攻击威胁:
因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
每个用户经过我们的应用认证之后，我们的应用都要在服务端做一次记录，以方便用户下次请求的鉴别，
通常而言session都是保存在内存中，而随着认证用户的增多，服务端的开销会明显增大。
扩展性有限:
用户认证之后，服务端做认证记录，如果认证的记录被保存在内存中的话，
这意味着用户下次请求还必须要请求在这台服务器上,这样才能拿到授权的资源，
这样在分布式的应用上，限制了负载均衡器的能力，这也意味着限制了应用的扩展能力。
CSRF攻击威胁:
因为是基于cookie来进行用户识别的, cookie如果被截获，用户就会很容易受到跨站请求伪造的攻击。
token 验证
它不需要在服务端去保留用户的认证信息或者会话信息。
这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录，这就为应用的扩展提供了便利。
这就意味着基于token认证机制的应用不需要去考虑用户在哪一台服务器登录，这就为应用的扩展提供了便利。
流程
- 用户使用用户名密码来请求服务器
- 服务器进行验证用户的信息
- 服务器通过验证发送给用户一个token
- 客户端存储token，并在每次请求时附送上这个token值
- 服务端验证token值，并返回数据
问题？？
缺陷是 token 只能当作身份认证凭证，但是 JWT 还可以传输其他必要数据 ？？？
JWT
Json web token (JWT),
是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准
是为了在网络应用环境间传递声明而执行的一种基于JSON的开放标准
构成
JWT由三段信息构成，将这三段信息文本用.链接一起就构成了Jwt字符串。
例如:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
例如:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
三部分
头部
jwt的头部承载两部分信息：
- 声明类型，这里是jwt
- 声明加密的算法 通常直接使用 HMAC SHA256
完整的头部就像下面这样的JSON：
{
'typ': 'JWT',
'alg': 'HS256'
}
然后将头部进行base64加密（该加密是可以对称解密的),构成了第一部分.
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
{
'typ': 'JWT',
'alg': 'HS256'
}
然后将头部进行base64加密（该加密是可以对称解密的),构成了第一部分.
eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9
载荷
载荷就是存放有效信息的地方，这些有效信息包含三个部分
- 标准中注册的声明
- 公共的声明
- 私有的声明
定义一个payload:
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
然后将其进行base64加密，得到Jwt的第二部分。
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
{
"sub": "1234567890",
"name": "John Doe",
"admin": true
}
然后将其进行base64加密，得到Jwt的第二部分。
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9
签证
由三部分组成：
- header (base64后的)
- payload (base64后的)
- secret
⚠️ 注意：secret是保存在服务器端的，jwt的签发生成也是在服务器端的，secret就是用来进行jwt的签发和jwt的验证，
所以，它就是你服务端的私钥，在任何场景都不应该流露出去。
一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。
所以，它就是你服务端的私钥，在任何场景都不应该流露出去。
一旦客户端得知这个secret, 那就意味着客户端是可以自我签发jwt了。
应用
一般是在请求头里加入Authorization，并加上Bearer标注：
fetch('api/user/1', {
headers: {
'Authorization': 'Bearer ' + token
}
})
fetch('api/user/1', {
headers: {
'Authorization': 'Bearer ' + token
}
})
优点
- 因为json的通用性，所以JWT可以进行跨语言支持，像JAVA,JavaScript,NodeJS,PHP等很多语言都可以使用。
- 因为有了payload部分，所以JWT可以在自身存储一些其他业务逻辑所必要的非敏感信息。
- 便于传输，jwt的构成非常简单，字节占用很小，所以它是非常便于传输的。
- 它不需要在服务端保存会话信息, 易于应用的扩展
缺点
- 服务器不保存会话状态，所以在使用期间没有取消令牌或更改令牌的权限。也就是说，一旦JWT签发，在有效期内将会一直有效。
- JWT本身包含认证信息，因此一旦信息泄露，任何人都可以获得令牌的所有权限。为了减少盗用，JWT的有效期不宜设置太长。对于某些重要操作，用户在使用时应该每次都进行进行身份验证。
- 为了减少盗用和窃取，JWT不建议使用HTTP协议来传输代码，而是使用加密的HTTPS协议进行传输。
OAuth（开放授权）
OAuth 是一种授权机制。
数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。
系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。
数据的所有者告诉系统，同意授权第三方应用进入系统，获取这些数据。
系统从而产生一个短期的进入令牌（token），用来代替密码，供第三方应用使用。
令牌特点
（1）令牌是短期的，到期会自动失效
（2）令牌可以被数据所有者撤销，会立即失效。
（3）令牌有权限范围（scope），只读令牌就比读写令牌更安全。
（2）令牌可以被数据所有者撤销，会立即失效。
（3）令牌有权限范围（scope），只读令牌就比读写令牌更安全。
参考
https://www.jianshu.com/p/576dbf44b2ae
https://baijiahao.baidu.com/s?id=1608021814182894637&wfr=spider&for=pc
http://www.ruanyifeng.com/blog/2019/04/oauth_design.html
职业：本科
0 条评论
下一页
