用户认证 之 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的认证交互流程比较清晰简单，如图：
添加图片注释，不超过 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 验证统一在网关处理，验证通过后放行到后端服务。
添加图片注释，不超过 140 字（可选）
