微服务架构权限验证系统除了 oauth2 外还有哪些解决方案？

• 資深大佬 : yc8332

  jwt

• 資深大佬 : xuanbg

  看我的 GitHub： https://github.com/xuanbg/gateway

• 主 資深大佬 : ReinerShir

  @xuanbg 在网关中鉴权会不会不大好？ 毕竟网关是每个请求都要通过的服务，请求量上来了影响效率

• 資深大佬 : xuanbg

  @ReinerShir 鉴权只需要 3ms，放哪里都差不多。再说，网关也可以有多个服务实例的呀，前面搞个 Nginx 做个负载均衡就行了。

• 資深大佬 : defage

  缓存

• 資深大佬 : johnsona

  oauth2 怎么搞呢？你自己搞一个 oauth2 server 授权吗？先自己描述清楚吧，据我所知，很多什么微服务 oauth2 的文章都在瞎扯。
  很简单一个办法，登陆之后，返回 token，token 存 redis，value 是 dict 数据，比如权限集之类的。
  请求来了直接去 redis 读取对应 token，比较权限就完事了
  那些博客都在乱扯，还有什么 jwt，你要真无状态了，怎么冻结别人账户，你还是存下来搞黑名单之类的

• 主 資深大佬 : ReinerShir

  @johnsona 这个方法我知道，但是会有一些问题 1 、每个服务都需要连接 redis 2 、所有服务都可以修改权限（就是我开头说的那个意思，会不会有安全问题）

• 資深大佬 : xuanbg

  @johnsona oauth2 和 jwt 是两码事。oauth2 可以用第三方的，也可以自己造轮子，我比较倾向于自造轮子。因为授权其实是和业务有关联的，虽然只是弱关联，但用第三方的总归是不得劲，还是自己搞一个最合适。

  不过我支持你关于 token 的说法，jwt 只适用不需要鉴权的 toC 系统或者权限较少的轻量级 toB 系统。稍微大一点的管理系统就不适合用 jwt 了。

• 資深大佬 : 5sheep

  少年，OAuth2.0 不是给微服务鉴权用的。 当然，你非说大炮也能打死蚊子，咱就不用往下交流了。

• 資深大佬 : xuanbg

  @ReinerShir 服务怎么可能去修改权限？授权是专门的一个模块 /服务。你可以看我的： https://github.com/xuanbg/insight_auth

• 主 資深大佬 : ReinerShir

  @5sheep 标题描述可能不大正确，我想说的是，微服务架构除了走统一鉴权服务外还有没有其它解决方案（因为每个请求都要去鉴权），我知道 oauth2 只是一种协议

  @xuanbg 嗯，我看了下，你这个框架应该也是走的统一认证服务，即每个请求都要去调鉴权接口，续期、删除等操作都是统一调用鉴权服务。

• 資深大佬 : okletswin

  OAuth 是做认证的，验证用户合法有效，非鉴权，权限的鉴定还需要你的系统自己实现

• 資深大佬 : xuanbg

  @ReinerShir 是的，基础就是 Auth 服务。我只是做了些优化，不需要每次都调用服务。当然也支持每次都调用服务，这样用户权限就可以实时更新。

• 資深大佬 : johnsona

  @xuanbg 你怎么搞

• 資深大佬 : opengps

  只有自己家的业务，直接 ip 白名单省心太多

• 資深大佬 : johnsona

  @xuanbg 我看到了

• 資深大佬 : johnsona

  @xuanbg 我个人觉得，一开始要不要搞复杂的鉴权，比如 rbac，因为你接口要定义权限，数据库要存储权限，还依赖后台管理系统去配置权限，这还只是功能权限，还有数据权限。还得看团队，团队其他人负责写业务逻辑的，还得提示人家在每个接口上面写上权限名或者权限码之类的，然后去后台自己配置一下，流程太繁琐了

• 資深大佬 : johnsona

  @ReinerShir oauth2 也是都要连接到一个 server 吧，权限是每个服务自己定义的，比如我这个服务的这个接口要求什么角色或者什么权限名才能访问，现在我变卦了，我说这个角色不让你访问，也没问题

• 資深大佬 : xuanbg

  @johnsona 你说的这些，在系统设计阶段规划好资源和对应接口 url 就行了，并不需要入侵到业务代码。我都是直接 sql 脚本写好，一次就导入了。也有后台可以配置，不过没有写脚本爽利。

  数据权限和业务耦合太紧密，我的权限框架就没有考虑支持。最早是有支持按组织机构配置数据权限的，后来觉得虽然可配置，但还得在业务代码里面去实现，不能做到完全脱离业务就干掉了。

• 資深大佬 : xuanbg

  @xuanbg 上面说到资源的配置，在资源配置或导入完成，就可以直接在角色管理里面给角色分配权限了。用户登录时就会根据角色分配的权限生成一个授权码集合，然后网关上面收到请求就会根据 url 对应的授权码对用户进行鉴权了。

• 資深大佬 : neetrorschach

  用过一次 oauth2，拿来认证用户合法可以，决定用户是否有权限不好做。当这个权限服务是某个区域内的公共服务时往往只能做到登录认证，至于用户是否有权限操作某些资源基本上还是在各自的子系统内实现的。需要子系统开发人员按照你的开发标准接入，对系统侵入比较大。
  我第一次开发接入 oauth2 的系统时，完全按照对方公司给的开发手册做的，每次请求都去 oauth2 系统验证 token 是否有效。系统上线半年后对方跟我说系统花了太多钱了，因为这个认证系统是 global 的，子公司使用按使用量计费。按照这个用法，每年要交给总部十几万。然后就改成认证一次，把 token 保留一星期，token 过期后用 refresh token 刷个新的。

• 資深大佬 : KuroNekoFan

  感觉认证和鉴权是两回事