权限认证 cookie VS token

权限认证 cookie VS token

我前公司的应用都是 token 授权的,现公司都是维护一个 session 确认登录状态的。那么我在这掰扯掰扯这两种权限认证的方方面面。

工作流程

先说 cookie

cookie 登录是有状态的,服务端维护一个 session 客户端维护一个 cookie,cookie 只保留 sessionID 服务端要保存并跟踪所有活动的 session 如下:

  1. 输入用户名密码登陆。
  2. 服务器拿到身份并验证后生成一个 session 存到数据库。
  3. 把 sessionID 返回给客户端存成一个 cookie 保存 sessionID。
  4. 随后的请求会携带这个包含 sessionID 的 cookie。
  5. 服务器拿着 sessionID 找到对应的 session 认证用户是否有对应权限啊。
  6. 登出后,服务端销毁 session 客户端销毁 cookie。

    token
    token 的认证方式是无状态的,服务端不保存登陆状态,也不关心哪些客户端签发了 token ,每个请求都会携带 token 通常在 header 中,也可以出现在 body 和 query 如下:
  7. 输入用户名密码登陆。
  8. 服务器拿到身份并验证后签发一个 token。
  9. 客户端拿到 token 并存起来,好多地方都可以存。
  10. 客户端发送的每一个请求都要携带 token,好多方式可以携带。
  11. 服务器接收请求后拿到 token 并解析,拿解析的结果进行权限认证(token中可能已经携带权限信息,能被正常解析的 token 被认为是合法机构签发的)。
  12. 登出后,在客户端销毁 token 即可。
    无图无真相,两种方式对比
    链接

    token 的优势

    新的东西如果没有原来的好用是不会有人用的。那 token 哪里好呢。
  • 无状态,token 是无状态的,服务器端不需要保留任何信息,每个 token 都会包含所有需要的用户信息。服务器端可以只负责签发和解析 token 解放了部分服务器资源,让服务器更单纯的提供接口。
  • 跨服务器,无状态优势在此。服务器如果做了负载均衡之类的,你两条请求不一定去同一个服务器,着如果用服务器维护一个 session 的话就显得有些棘手了,一个服务器和一个客户端对应,另一个服务器不一定认得你啊,不对是一定不认得你啊,当然这个问题也不难解决。
  • 可以携带其他信息,比如携带具体权限信息之类的,省的还要去查库。
  • 性能,解 token 可比查库要省事儿的多。
  • 跨域,请求需要跨域的接口的时候 cookie 就力不从心了,不同域就不会携带 cookie ,不携带 cookie 服务器也不知道是哪个 session 啊,token 在此优势明显。
  • 配合移动端,cookie 是浏览器端的玩意儿,移动端应用想使用 cookie 还得折腾一下,token 就方便得多。token 让服务器端单纯提供 API 服务,适用性更广。
  • CSRF,如果 token 不存放在 cookie 中,防止了跨站请求伪造带来的安全性风险。
    参考:地址
  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
本课程是一门具有很强实践性质的“项目实战”课程,即“企业中台系统实战”,其中主要包含三大块核心内容,如下图所示(右键可以在新标签页中打开图片放大查看): 即主要包含以下三大块内容: ① 企业内部应用系统菜单资源和操作权限的统一管理; ② 分布式应用系统通信时的统一授权,即基于AccessToken的授权与认证; ③ 分布式服务/系统通信时的两大方式(基于dubbo rpc协议和基于http协议的restful api实战)。   值得一提的是,这套中台系统由于讲解了如何统一管理企业内部各大应用系统的“菜单资源列表”、“操作权限”,故而本门课程的“代码实战”是建立在之前debug录制的“企业权限管理平台”这套课程的基础之上的,故而在这里debug建议没有项目开发基础的小伙伴可以先去学习我的那套“企业权限管理平台”的实战课程,之后再来学习我的这套中台系统的实战才不会很吃力(课程链接:)   本课程的课程大纲如下图所示(右键可以在新标签页中打开图片放大查看):   除此之外,这套“中台系统”由于统一管理了企业内部各大应用系统的“菜单资源和操作权限”以及“应用系统之间通信时的统一授权”,故而难免需要涉及到“中台系统”与“中台子系统”、“中台子系统”与“中台子系统”之间的通信(即分布式服务之间的通信),在这里我们是采用“dubbo + zookeeper”的方式加以落地实现的,详情如下图所示(右键可以在新标签页中打开图片放大查看):   而众所周知,作为一款知名以及相当流行的分布式服务调度中间件,dubbo现如今已经晋升为Apache顶级的开源项目,未来也仍将成为“分布式系统”开发实战的一大利器,如下图所示为dubbo底层核心系统架构图(右键可以在新标签页中打开图片放大查看): 而在这门“中台系统实战”的课程中,我们也将始终贯彻、落地dubbo的这一核心系统架构图,即如何将中台系统开发的服务注册/发布到注册中心zookeeper,中台子系统如何订阅/消费/调度中台系统发布在zookeeper的接口服务,中台子系统在走http协议调度通信时dubbo如何进行拦截、基于token认证接口的调用者等等,这些内容我们在课程中将一一得到代码层面的实战落地!   下图为本课程中涉及到的分布式系统/服务之间 采用“http协议restfulapi”方式通信时的Token授权、认证的流程图(右键可以在新标签页中打开图片放大查看): 而不夸张地说,基于AccessToken的授权、认证方式在现如今微服务、分布式时代系统与系统在通信期间最为常用的“授权方式”了,可想而知,掌握其中的流程思想是多么的重要!   以下为本门课程的部分截图(右键可以在新标签页中打开图片放大查看):     核心技术列表: 值得一提的是,由于本门课程是一门真正介绍“中台思想”以及将“中台思想”和“分布式系统开发实战”相结合落地的课程,故而在学完本门课程之后,可以掌握到的核心技术自然是相当多的。主要由SpringBoot2.0、SpringMVC、Mybatis、Dubbo、ZooKeeper、Redis、OkHttp3、Guava-Retrying重试机制、JWT(Json Web Token)、Shiro、分布式集群session共享、Lombok、StreamAPI、Dubbo-Filter以及ServiceBean等等。如下图所示(右键可以在新标签页中打开图片放大查看):

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值