用户认证 之 CAS vs JWT
网络服务离不开用户认证,用户登录输入账号密码登录成功后,允许访问服务,假如公司有多个系统,如订单管理系统(oms),商品管理系统(pms),客户管理系统(crm),希望登录一次后都可以访问,否则每个系统单独登录体验很差,这就是 SSO-Single Sign On 单点登录。
cas 与 jwt 都是做权限身份验证,都可以实现单点登录,但实现思路却完全不同,最主要的区别就是cas 用户信息存在服务端session, jwt 用户信息以token的形式存在客户端。
CAS
CAS(Central Authentication Service) 是 Yale 大学发起的构建 Web SSO 的 开源项目,他产生的比较早主要是PC时代,设计的也很好,但不太适应现在的app时代。
cas流程:用户访问 oms 系统,过滤器拦截请求发现没有登录,就跳转到cas server 去登录,登录完成后签发一个ST,重定向到oms系统,oms拿着回传的参数ST去CAS验证,验证通过后,允许用户访问资源。但如果是前后端分离的应用,系统就由原来的单个应用,分为前后端分开部署(动静分离),前端的静态服务(html,css.js),后端服务(api接口),这时用户浏览器先访问前端加载静态资源,然后再向后端api发起请求,后端api 接口通过过滤器鉴权。如果cas server 登录后跳转到后端服务地址肯定是不行的,因为没有界面,这时候需要在服务端完成验证后继续跳转到前端地址;
因为要利用浏览器重定向,所以只能在pc 上运行,app 全是接口交互。
JWT
JSON Web Token(缩写 JWT)
jwt的认证交互流程比较清晰简单,如图:
![](https://pic1.zhimg.com/80/v2-7f8d8ec58ea3f90250bc60129335fc78_1440w.jpeg?source=d16d100b)
添加图片注释,不超过 140 字(可选)
用户请求服务如果没有携带token服务会返回403无权限的json(当然这个验证token可以统一放到网关去做),用户要登录,登录成功后签发token,客户端把token保存到本地,后面的请求都带上token。
下面是用ES256 签名方式生成的 token的样例:
eyJraWQiOiJFRjRGMjJDMC01Q0IwLTQzNDgtOTY3Qi0wMjY0OTVFN0VGQzgiLCJhbGciOiJFUzI1NiJ9.eyJpc3MiOiJ4eHguY29tIiwiYXVkIjoicGMiLCJzdWIiOiJ0aW5hIiwiaWF0IjoxNjM3NzQ5Mzk3LCJleHAiOjE2Mzc3NTY1OTcsImp0aSI6ImQ0YzE3NWRjLTFlNGMtNGFkNi1hODBlLWJkYzkyMGEwZWE3MiIsInVpZCI6MTIzLCJyb2xlIjoiYWRtaW4ifQ.VMq2mPaFFEcDSytcG3u1xUwJw66FJawlrfdi4rfQVOhhPBt3sAcT4vuldHzDbPkGmI7RU7Z4rzk4Pr_jo9IPVg
分三段,第一部分是头,元信息,说明使用的加密的算法,第二部分是消息体,就是用户的一些信息,json格式base64编码,最后一部分就是前面信息的摘要签名,防止对token内容的篡改。前面两段都是明文可以用base64直接解码。
jwt的详细介绍可以参考:JSON Web Token 入门教程 - 阮一峰的网络日志 (ruanyifeng.com) token 的形式
由于token里面包含了用户的身份信息,比如userId, 后端服务每次只需要从请求头里解析token就可以拿到用户信息,不需要在session保存,这样就很灵活,不论是集群部署,还是多个不同的服务,只要token有效都可以访问,而且更轻量化,面对互联网海量的用户场景,也不会给服务端带来太大压力。
现在无论是web前后端分离,还是app jwt都可以适用,下面我画的图,体现了这种验证方式总体的架构,token 验证统一在网关处理,验证通过后放行到后端服务。
![](https://pic1.zhimg.com/80/v2-98217d21af58436e339a5d8b1a6d9255_1440w.jpeg?source=d16d100b)
添加图片注释,不超过 140 字(可选)