开放平台：权限校验auth框架

背景：
门户网站分为我的用户，我的开发者，机构用户，页面不一样的操做须要特定的用户才能操做。如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过时，说明需从新登陆