学习笔记之开发相关概念（7）--认证和授权

最新推荐文章于 2024-06-22 17:44:41 发布

华月箜篌

最新推荐文章于 2024-06-22 17:44:41 发布

阅读量431

点赞数

分类专栏：学习笔记文章标签：开发概念

本文链接：https://blog.csdn.net/huayuekonghoui/article/details/78952254

版权

学习笔记专栏收录该内容

66 篇文章 0 订阅

订阅专栏

认证（Authentication）解决你是谁的问题，授权（Authorization）解决你能干什么的问题。由于HTTP是无状态协议，客户端和服务端无法记住彼此，必须借助某些机制实现认证与授权。目前常用的认证授权机制包括cookie-session、OAuth和JWT(JSON WEB TOKEN)，下面介绍下cookie-session和JWT。OAuth没用过不谈！

一、cookie-session

服务端在成功验证用户的登录信息后，创建session并赋予其唯一的标识sessionID，然后将该用户的个人信息与权限信息存入此session中，最后将sessionID写入响应首部的Set-Cookie中。客户端收到响应后就会自动将sessionID存入cookie中，这样当前域下的所有请求都会自动将cookie中的sessionID置于请求首部的Cookie中（cookie不允许跨域请求）。服务端就可以根据sessionID找到具体的session，并获取其中的用户信息与权限信息，这样就实现了认证和授权。

二、JWT

服务端在成功验证用户的登录信息后，根据用户信息，权限信息和自定义密钥生成token，然后将token传给客户端。客户端首先解析token中的权限信息进行页面授权，并将token存在cookie（这样无法进行跨域请求，不推荐）或者localstorage中，如果token存在localstorage中就要手动将token写入到请求首部的Authorization中（Authorization:Bearer token）。服务端接收请求后，会优先在请求首部的Cookie中寻找token，如果没有就去Authorization找，都没找到则返回401错误。找到后根据自定义密钥对此token进行检验，如果合法即认证成功（不合法也返回401），然后解析token中的用户信息与权限信息，进行操作授权与业务授权。

JWT分为三个部分：头、负载和签名。头用于描述关于该JWT的最基本的信息，例如其类型以及签名所用的加密算法等；负载中存有若干JWT标准所定义的字段（如token签发时间，过期时间等），还可以添加用户信息和权限信息。实际上头与负载都是json，将这两个json分别进行Base64编码得到两个字符串，然后将这两个字符串拼接起来得到一个拼接字符串。签名就是将拼接字符串通过头中声明的加密算法与自定义密钥进行加盐加密得来的，将签名拼在拼接字符串后面，就得到了token。在服务端进行用户认证时，只要使用自定义密钥和签名加密算法将签名解密，并与头+负载的拼接字符串进行比对即可验证token的合法性。

附：

授权，分为页面授权、操作授权、数据授权
1.授权也是借助token实现的，在token中的permissions数组中设置菜单权限，前端页面通过解析token中的permission数组，进行前端react路由配置，规定用户可见的菜单（单页应用是这么玩的，非单页应用应该不用前端进行页面授权，而是由后端返回该用户可访问的页面url）。比如permissions中含有1才能访问会议系统，permissions中含有2才能访问设备系统。--页面授权
2.但是这样授权还没有完善，用户可以通过浏览器拿到token，然后根据现有接口的url风格，使用POSTMAN等工具尝试调用其它接口。比如某用户只有会议系统的权限，会议系统某接口的url是xxx/api/conference/msg?id=1，用户拿到token后使用POSTMAN尝试调用xxx/api/device/msg?id=1，这样设备系统的数据就会泄露。为了解决这个问题，不仅前端要进行页面授权，后端也要针对每个REST接口进行授权，比如xxx/api/conference/msg只能是permissions含有1才能调用，xxx/api/device/msg只能是permissions含有2才能调用。--操作授权
3.这样授权依旧没有完善，用户可以通过改变请求参数获取别人信息。还是刚才的例子，调用xxx/api/conference/msg?id=2就可以看到别人的会议信息。解决这个问题只能在程序或sql中进行逻辑控制，比如先从token中获取其userId，通过userId拿到用户所有的会议，再与请求参数做对比，判断该用户是否具有请求参数中的会议。如果用户确实有这个会议，再将查询结果返回；但如果用户没有此会议，返回一个错误响应。--数据授权

三、JWT相比于cookie-session的优点

cookie不支持跨域访问，JWT可以（前提是通过请求首部的Authorization传输token）
JWT机制不需要在服务端创建session，减少服务端压力
在分布式应用中，要将同一份session复制到集群的所有机器中（因为不能确定到底是哪台服务器处理用户请求），增大服务端压力；JWT机制只需要服务端持有密钥即可完成认证授权，更加方便
因为有了负载部分，所以JWT机制可以在token中存储一些其他业务逻辑所必要的非敏感信息。