@xomix 整体和单独做认证授权都试过，就是各有各的问题，因为是自己摸索的，所以想了解下有没有更好的实践。token 直接鉴权的方式只适合于 C 端用户权限不负责的情况，但是对于有 RBAC 要求的就不行了。签名部分仅保证传输的安全性，不适合用作用户维度的认证。

@twl007 好像是 CNCF 孵化的东西，了解看看。

@xuanbg
A1：对的，现在这种方案统一在 gateway 层做 url 级的授权校验。
A2：非自增也无法保证安全性。因为这种接口其实是拆分后无法 join 表用的基础接口，仅内部调用的。
A3：就是网关所以需要一个用户 token 才能调用，而且这个 token 必须映射到一个用户上去。

@lihongming 嗯嗯，网关其实只是一部分。其实很多问题不仅仅在网关，而是服务之间的治理和编排上。

@Evilk 是的，其实 80%的所谓微服务顶多就算服务化，还没到微服务化的水平。更多的不是为了业务而是为了微服务而微服务。

@Kyle18Tang
A1：是的，JWT 自验证就是为了减少获取用户信息的请求。认证没问题，但是每个服务的 RBAC 的授权就还没什么好的解决方案。
A2：是的，目前类似这么做，但是因为业务服务需要知道当前用户，因此 client credentials 无用户对应所以不太适用。

@paragon
和 @linvon 的 Q1 描述的一样，认证没问题，但是授权的问题还是存在每个被调用的服务都要去拿一遍用户的角色以及权限等信息。这里网络请求会变成 2n 次

@yaming116 哈哈，这不是协议的问题。

@linvon
A1：我们有考虑过，token 认证完成后南向的服务请求直接传递 uid，但是授权的问题还是存在每个被调用的服务都要去拿一遍用户的角色以及权限等信息。这里网络请求会变成 2n 次。
A2：是的，部署没问题。例如“用户服务”里面有很多接口，其中包括“通过用户 ids 批量获取用户信息”等基础接口供其他服务调用。因为 Gateway 直接路由到“用户服务”，就相当于能访问该服务所有的接口。如果要限制，就需要人工声明管理哪些接口是基础的不给外部调用的。这也是我们目前的做法，维护成本太高。
A3：因为会调用业务服务，所以模拟 token，但是由于 token 是对应用户的，所以这里面需要指定一个“系统用户”去对应 token （默认用户设计）。因为对数据修改需要获取修改人记录日志。

临时和永久做法都是一样的，关键是 token 需要对应一个用户（现在对应一个叫做“系统用户”的用户），token 做认证，用户信息做授权，所以这种做法感觉不够优雅。

@ZSeptember

a1：这种方式考虑过，但是由于服务与服务之间调用不走 gateway 的，所以这种从服务内安全性和我 q3 问题还是本地调试都需要手动填写相关授权信息。

a2：是的，需要定制网关，但是就需要成本去维护那些接口不被外部调用，这里面会存在遗漏。

a3：但是被调用的服务其实用户也会用到，定时任务也会用到，所以没法很好的区分两种授权方式

@zhazi 认证已经使用了 oauth2 了，但是 rabc 的授权还是做的不够优雅。

@imherer 谢谢回复，现在已经是 oauth2 授权模式了。还有签名仅用做数据的有效性校验，跟认证授权应该是不一样的。去请求 token 也可以，但是你通过哪个用户信息去请求，因为这里是非用户发起的。

@xomix 这个抽象理解的很好，token 仅做认证，授权应该业务服务做准入实现。但是这也造成在调用链路中每个参与者都需要去获得用户权限并验证的问题。

社会主义岛

可以去了解下 squid

@Orciorc 我也是观望着一些网上销售的网红型的保险，两三千保额就 50 万，不知道有没有坑。

@woodensail 嗯嗯，还是得靠自己去了解一下保险的东西，网上和线下找保险代理人不知道有什么差别，怕是假设到时候要报保险比较麻烦。