微服务鉴权_OpenID Connect作为微服务系统的认证鉴权机制

在我的微服务架构系列文章

基于CSE的微服务架构实践-基础架构_云博客_云社区-华为云​bbs.huaweicloud.com

介绍了一种弹性的微服务架构。本文以这个架构为基础，探讨微服务鉴权机制设计的一些问题。

弹性微服务架构

JWT[1]作为一种无状态的鉴权机制，特别适用于微服务架构。在JWT基础上发展起来的OAuth2[2]、OpenID Connect[3]成为了业界云厂商标准的鉴权机制。

[1] 什么是JWT

什么是 JWT -- JSON WEB TOKEN​www.jianshu.com

[2] 理解OAuth 2.0

理解OAuth 2.0 - 阮一峰的网络日志​www.ruanyifeng.com

[3] Understanding OAuth 2.0 and OpenID Connect

https://blog.runscope.com/posts/understanding-oauth-2-and-openid-connect​blog.runscope.com

OAuth2通常被设计为访问第三方服务，它的密码模式和客户端模式也非常适合业务系统自身的认证（本地认证）。提供一套统一的方案实现本地认证和第三方认证，对于系统能力开放将是非常有意义的。目前我的工作就是基于ServiceComb构建这样的认证鉴权系统，现在已经实现了原型系统：

apache/servicecomb-samples​github.com

每个服务在认证过程中扮演的角色

• 认证服务(Authentication Server)

1. 在本地认证模式下：用户输入用户名、密码等信息，返回访问Token（Access Token）。比较类似于客户端模式或者密码模式。
2. 在第三方认证模式下：支持授权码认证模式，将用户请求重定向到第三方服务，得到授权后，使用授权码访问第三方服务获取访问Token。

• 网关（Gateway）

1. 必要的协议适配。比如读取HTTP的Authentication头，供后续流程处理。
2. 请求路由。比如访问Authentication Server的请求不认证，访问其他服务的请求认证，并拒绝非法访问。同时支持其他灵活的访问控制。

• 资源服务（Resource Server）

1. 拦截请求，进行认证（可选）
2. 拦截请求，对请求的资源进行鉴权

可以看到和传统应用在鉴权逻辑上的一个重要区别：没有会话管理。用户的权限信息包含在了Access Token里面，资源服务通过解析权限信息，就能够实现本地认证。这个就非常适用于微服务的无状态设计和独立部署等设计原则。

• 探讨问题和后续计划

1. 网关认证以后，资源服务是否需要认证
2. 权限信息是配置在每个微服务好，还是统一配置在认证服务
3. 目前项目提供的是一个流程示例，基本可以支撑业务系统基于ServiceComb开发自己的认证鉴权系统了。后续会推动项目作为ServiceComb的一个子项目，提供认证鉴权的公共组件，并且会进一步完善项目功能，参考OpenConnect ID等规范，做一个标准的实现。对于ServiceComb或者认证鉴权感兴趣的开发者可以关注项目进展，参与一起贡献，欢迎订阅 [email protected] 邮件列表。