背景：
门户网站分为个人用户，集体开发者，机构用户，页面不同的操作须要特定的用户能力操作。如 api 申请，密钥下载只有机构用户才可操作，重置明码须要登录后才可操作。
治理端分为系统管理员，开放平台管理员，银行管理员，不同的角色具备不同的权限，
权限按资源划分
服务间调用也须要进行爱护，如调用发送短信接口，调用发送站内信的接口，不能不加限度地对外裸露。
因而须要以接口为粒度进行对立鉴权，在接口处注明须要的权限，需注明申请起源：门户，治理端，服务间调用。如果是门户或治理端，还可标注须要的角色或资源。可校验多个起源。
技术设计：
对于门户网站和治理端，用户登录胜利后生成蕴含用户信息（userId）的 JWT token，前端保留在 vuex 中。每次操作申请将 token 放入 front- Authorization 和 manage- Authorization 以供服务端校验。其中 front 和 manage 代表源自门户和治理端。
服务间调用发送 http 申请时，在 header 处增加 service- Authorization，值为有效期为 30s 的 JWT token，service 代表源自服务间调用。
通过注解标记须要校验的接口，并增加所须要的申请起源和资源名称，如果匹配则放行，否则报无权限申请。
利用拦截器对申请进行切面操作，如果该办法加 @AuthRequest 注解则寻找 header，若蕴含 front- Authorization，manage- Authorization 或 service- Authorization，则对该 token 进行 JWT 校验。其中 front 和 service 校验较为简单，间接校验即刻，manage 校验 token 胜利后还需从 token 中获取 userId，通过服务间调用判断该用户是否领有该资源。如果门户和治理端校验胜利，从 token 中取出 userId，role 放入 attribute，供接口应用。
引入该包还为 feign 调用增加 service- Authorization 的 header
流程图：
阐明：
门户网站，治理端和服务间调用通常通过 gateway，然而对立校验不在 gateway，而在各自服务，起因如下：
- 更平安，有的申请可能间接通过服务调用，而非 gateway，因而须要在服务的接口层面做校验
- 配置更不便
权限是一种安全策略，用户只可拜访被受权的资源。因而须要采取策略管制用户的行为。
波及到以下几个方面：
- 用户认证：如何校验用户的合法性并保留用户的登录状态
- 权限校验：如何爱护服务端的接口，用户是否有资格调用接口，包含：从 web 端发送来的申请，服务间的调用
- 权限治理：如何给用户分配资源，RBAC
权限性能在服务从单体转向微服务架构面临如下挑战：
- 如何保障用户的登录状态。单体中可将登录状态保留至 session 中，但微服务中利用被分为多个服务，服务应该是无状态的，不能保留用户的登录状态；
- 微服务拆分后，调用起源不仅仅是客户端，还有来自服务间的调用，因而须要全面思考多个起源的调用
- 权限校验性能不能散落在各个服务中，应对立解决
- 前后端拆散，只做数据交互，前端路由 / 按钮资源化，如何治理资源
微服务利用的权限性能应具备特点：
- 与业务零碎解耦，性能独立，职责繁多
- 保障可用性，当权限服务不可用时，不能扭转业务零碎的行为
- 保障性能，防止因鉴权导致响应工夫减少
- 对已有代码侵入性小，革新不便
现有的解决方案：
- Oauth2：受权框架
- JWT token：认证协定
- Security：有些重
- Shiro：可做权限认证，明码加密等，但不太实用于微服务环境，SecurityManager
- 分布式 session：将 username，session id 作为 key 存储至分布式存储中，用户拜访微服务时，能够从分布式存储中断定。保障了高可用和可扩大。毛病是存在安全隐患。
通过比拟，决定自行研发一套权限校验框架，包含：
- JWT Token 进行用户认证及鉴权
- RBAC 权限调配体系
架构图：
Token 设计
一段字符串，用户登陆胜利后服务端生成返回至客户端保留，作为后续已登陆状态的凭证。
长处：
- 每次申请将 token 放入 header 中，可防止 CSRF
- 本身无状态，可在服务间共享，服务端不保留 token 仍可校验其合法性。（不必在服务端保留 k -v）
应具备以下特点：
- 一个 Token 就是一些信息的汇合，蕴含如 username，phone-number，资源等信息；
- 可作为用户认证的凭据。因为 token 是被签名的，服务端可对 cookie 和 HTTP Authrorization Header 进行 Token 信息的查看，如果校验非法，可认为该申请是平安的
- Token 有肯定的有效期，保障安全性
- Token 在有效期内无效，无奈通过本身生效，除非通过放入 redis 辅助校验
过期策略：
Token 过期后应进行续签，而不是跳转到登陆画面，造成蹩脚的用户体验。Token 生效工夫过长会存在安全性隐患，过短会造成频繁的 refresh token。好的体验应该是在用户无感知的状况下进行 token 刷新。
- 服务端保留 token 状态，用户每次操作均刷新 token 有效期，可做到一段时间没有操作即登出，但这种计划对内存压力较大，每次操作都要拜访，失去了 token 可被验证的便捷性
- refresh token：用户登陆胜利后返回 token 及 refresh token，token 过期后通过 refresh token 续签 token，token 有效期短而 refresh token 有效期长，refresh token 生效后认为登出。可实现每次登陆保留登录状态肯定工夫。能够防止对内存的频繁读写
何时 refresh token：
- 前端建设定时工作每隔肯定工夫通过 refresh token 获取新 token
- 收到响应后，如果响应为 token 过期，通过 refresh token 获取新 token，再次发送申请，如果 refresh token 过期，阐明需从新登录