微服务架构统一安全认证设计与实践

标签: 微服务 架构 统一 | 发表时间:2021-01-19 10:56 | 作者:老马
出处:http://weekly.dockone.io

【编者的话】当企业应用系统逐渐增多后,每个系统单独管理各自的用户数据容易形成信息孤岛,分散的用户管理模式阻碍了企业应用向平台化演进。当企业的互联网业务发展到一定规模,构建统一的标准化账户管理体系将是必不可少的,因为它是企业互联网云平台的重要基础设施,能够为平台带来统一的帐号管理、身份认证、用户授权等基础能力,为企业带来诸如跨系统单点登录、第三方授权登录等基础能力,为构建开放平台和业务生态提供了必要条件。

名词定义

  • Third-party application:第三方应用程序,本文中又称“客户端”(client)。
  • HTTP service:HTTP服务提供商,本文中简称“服务提供商”。
  • Resource Owner:资源所有者,本文中又称“用户”(user),即登录用户。
  • User Agent:用户代理,本文中就是指浏览器。
  • Authorization server:认证服务器,即服务提供商专门用来处理认证的服务器。
  • Resource server:资源服务器,即服务提供商存放用户生成的资源的服务器。它与认证服务器,可以是同一台服务器,也可以是不同的服务器。


研发背景

单体应用体系下,应用是一个整体,一般针对所有的请求都会进行权限校验。请求一般会通过一个权限的拦截器进行权限的校验,在登录时将用户信息缓存到 session 中,后续访问则从缓存中获取用户信息。

随着 Restful API、微服务的兴起,基于 Token 的认证现在已经越来越普遍。Token 和 Session ID 不同,并非只是一个 key。Token 一般会包含用户的相关信息,通过验证 Token 就可以完成身份校验。

基于 Token 认证的优势如下:
  • 服务端无状态:Token 机制在服务端不需要存储 session 信息,因为 Token 自身包含了所有用户的相关信息。
  • 性能较好,因为在验证 Token 时不用再去访问数据库或者远程服务进行权限校验,自然可以提升不少性能。
  • 支持移动设备,支持跨程序调用,Cookie 是不允许垮域访问的,而 Token 则不存在这个问题。


研发目标

通过标准安全认证流程,异构系统或跨服务间能够灵活地实现指定功能部件或服务的集成、统一的安全认证。

基于 Token 认证的一个典型流程如下:
  1. 用户输入登录信息(或者调用 Token 接口,传入用户信息),发送到身份认证服务进行认证(身份认证服务可以和服务端在一起,也可以分离,看微服务拆分情况了)。
  2. 身份验证服务验证登录信息是否正确,返回接口(一般接口中会包含用户基础信息、权限范围、有效时间等信息),客户端存储接口,可以存储在 Session 或者数据库中。
  3. 客户端将 Token 放在 HTTP 请求头中,发起相关 API 调用。
  4. 被调用的微服务,验证 Token 权限。
  5. 服务端返回相关资源和数据。


安全认证功能点:

  1. 获取凭证,第三方应用客户端使用客户端编码/安全码、资源所有者用户名/密码等证件信息从授权服务器上获取 Access Token 资源访问凭证。
  2. 登录授权,客户端携带 Access Token 凭证访问服务器资源,资源服务器验证 Token、第三方应用凭证信息、资源所有者 User 合法性,通过 Token 读取资源所有者身份信息(user)加载资源所有者的权限项执行登录。
  3. 访问鉴权,第三方应用客户端访问服务端资源,系统验证访问者 Access Token 合法性、权限信息,验证凭证(Access Token)正确,此时资源服务器就会返回资源信息。
  4. 凭证续约,Access token 访问凭证过期需要进行凭证续约,刷新 Token 凭证有效期。


技术选型分析

  • 系统授权采用 OAuth2 开放式授权标准密码模式。
  • Token 采用 JWT 标准。


OAuth 开放授权

OAuth(Open Authorization,开放授权)是为用户资源的授权定义了一个安全、开放及简单的标准,第三方无需知道用户的账号及密码,就可获取到用户的授权信息。

主要的四种授权方式:
  • 授权码模式(authorization code)用在客户端与服务端应用之间授权码。
  • 简化模式(implicit)用在移动 app 或者 web app(这些 app 是在用户的设备上的,如在手机上调起微信来进行认证授权)。不通过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了“授权码”这个步骤,因此得名。所有步骤在浏览器中完成,令牌对访问者是可见的,且客户端不需要认证。
  • 密码模式(resource owner password credentials)应用直接都是受信任的(都是由一家公司开发的)密码模式中,用户向客户端提供自己的用户名和密码。客户端使用这些信息,向“服务商提供商”索要授权。在这种模式中,用户必须把自己的密码给客户端,但是客户端不得储存密码。
  • 客户端模式(client credentials)用在应用 API 访问客户端模式(Client Credentials Grant)指客户端以自己的名义,而不是以用户的名义,向“服务提供商”进行认证。严格地说,客户端模式并不属于 OAuth 框架所要解决的问题。在这种模式中,用户直接向客户端注册,客户端以自己的名义要求“服务提供商”提供服务,其实不存在授权问题。


Json Web Token(JWT)

Json Web Token(JWT),是为了在网络应用环境间传递声明而执行的一种基于 JSON 的开放标准(RFC 7519)。该 Token 被设计为紧凑且安全的,特别适用于分布式站点的单点登录(SSO)场景。JWT 的声明一般被用来在身份提供者和服务提供者间传递被认证的用户身份信息,以便于从资源服务器获取资源,也可以增加一些额外的其它业务逻辑所必须的声明信息,该 Token 也可直接被用于认证,也可被加密。

认证流程逻辑

系统授权

第三方应用客户端使用客户端编码/安全码、资源所有者用户名/密码等证件信息从授权服务器上获取 Access Token 资源访问凭证。

系统授权颁发给客户应用 Access Token。

系统鉴权

客户端携带 Access Token 凭证访问服务器资源,资源服务器验证 Token、第三方应用、资源所有者 User 合法性,通过 Token 读取资源所有者身份信息(user)加载资源所有者的权限执行登录。

系统验证访问者 Access Token 合法性、权限信息,验证凭证(Access Token)正确,此时资源服务器就会返回资源信息。

凭证续约

Access Token 访问凭证过期需要进行凭证续约,刷新 Token 凭证有效期。

接口设计

授权凭证

获取授权凭证,校验客户端身份信息、校验资源所有者身份信息,下发 Token 凭证。

客户端编码/安全码需要第三方应用到系统注册审核通过后生成。


授权凭证续约

获取续约授权凭证,校验客户端身份信息、校验 RefreshToken 凭证,下发 Token 凭证。




原文链接: https://juejin.cn/post/6906149001520037902,作者:mars

相关 [微服务 架构 统一] 推荐:

微服务架构统一安全认证设计与实践

- - DockOne.io
【编者的话】当企业应用系统逐渐增多后,每个系统单独管理各自的用户数据容易形成信息孤岛,分散的用户管理模式阻碍了企业应用向平台化演进. 当企业的互联网业务发展到一定规模,构建统一的标准化账户管理体系将是必不可少的,因为它是企业互联网云平台的重要基础设施,能够为平台带来统一的帐号管理、身份认证、用户授权等基础能力,为企业带来诸如跨系统单点登录、第三方授权登录等基础能力,为构建开放平台和业务生态提供了必要条件.

谈微服务架构

- - 人月神话的BLOG
其实在前面很多文章谈到SOA,特别是系统内的SOA和组件化的时候已经很多内容和微服务架构思想是相同的,对于微服务架构,既然出现了这个新名称,那就再谈下微服务架构本身的一些特点和特性. 从这个图可以看到微服务架构的第一个重点,即业务系统本身的组件化和服务化,原来开发一个业务系统本身虽然分了组件和模块,但是本质还是紧耦合的,这关键的一个判断标准就是如果要将原有的业务系统按照模块分开部署到不同的进程里面并完成一个完整业务系统是不可能实现的.

微服务与架构师

- - 乱象,印迹
因为工作的关系,最近面试了很多软件架构师,遗憾的是真正能录用的很少. 很多候选人有多年的工作经验,常见的框架也玩得很溜. 然而最擅长的是“用既定的技术方案去解决特定的问题”,如果遇到的问题没有严格对应的现成框架,就比较吃力. 这样的技能水平或许适合某些行业,但很遗憾不符合我们的要求. 软件架构师到底应该做什么,又为什么这么难做好,这都是近来的热门问题,我也一直在和朋友们讨论.

全方面解析微服务架构下的统一身份认证和授权 - 知乎

- -
本文讨论基于微服务架构下的身份认证和用户授权的技术方案,在阅读之前,最好先熟悉并理解以下几个知识点:. 微服务架构相关概念:服务注册、服务发现、API 网关. 身份认证和用户授权:SSO、CAS、OAuth2、JWT. 文章在涉及到上述知识内容时,会附上参考链接. 当企业的应用系统逐渐增多后,每个系统单独管理各自的用户数据容易行成信息孤岛,分散的用户管理模式阻碍了企业应用向平台化演进.

面向服务与微服务架构

- - CSDN博客推荐文章
最近阅读了 Martin Fowler 和 James Lewis 合著的一篇文章  Microservices, 文中主要描述和探讨了最近流行起来的一种服务架构模式——微服务,和我最近几年工作的实践比较相关感觉深受启发. 本文吸收了部分原文观点,结合自身实践经验来探讨下服务架构模式的演化. 面向服务架构 SOA 思想概念的提出已不是什么新鲜事,大概在10年前就有不少相关书籍介绍过.

微服务架构实践感悟

- - mindwind
从去年初开始接触微服务架构的一些理念,然后到今年开始实施系统第四个大版本的架构升级决定采用这套架构理念. 最近关于微服务架构的讨论还是多起来,因为国外一些著名互联网公司(如:Amazon、Netflix 等)从实践中摸索出了一套新的大型系统架构方法论,并取得了成功,树立了很好的示范,然后这套方法论渐渐就被一些技术理论派 人士命名为微服务架构(Microservices).

微服务架构成功之路

- - CSDN博客推荐文章
本文来源于我在InfoQ中文站翻译的文章,原文地址是:http://www.infoq.com/cn/news/2015/07/success-of-microservices. 近年来,在软件开发领域关于微服务的讨论呈现出火爆的局面,有人倾向于在系统设计与开发中采用微服务方式实现软件系统的松耦合、跨部门开发;同时,反对之声也很强烈,持反对观点的人表示微服务增加了系统维护、部署的难度,导致一些功能模块或代码无法复用,同时微服务允许使用不同的语言和框架来开发各个系统模块,这又会增加系统集成与测试的难度,而且随着系统规模的日渐增长,微服务在一定程度上也会导致系统变得越来越复杂.

微服务架构-模块迁移

- - 人月神话的BLOG
对于遗留的单体应用,要进行微服务架构的改造往往比一个全新应用基于微服务架构实现更加困难. 对于单体应用的微服务架构改造,最常见的方式仍然是将低耦合的模块逐步迁出. 下面以一个采购系统中招投标模块迁出为例进一步思考单体应用的微服务架构改造步骤. 在整个模型中我们将模型进行简化,当迁出一个功能模块进行微服务化的时候,首先要考虑的就是对该模块进行集成架构分析,考虑该模块和外围的集成情况,其次才是考虑该模块内部的私有数据.

SOA和微服务架构沟通(2.8)

- - 人月神话的BLOG
今天在广州交流SOA和微服务架构,特对关键内容做简单记录. 对于SOA和微服务架构的区别,在知乎一个回答里面我已经进行了详细的说明,即微服务架构强调的第一个重点就是 业务系统需要彻底的组件化和服务化,原有的单个业务系统会拆分为多个可以独立开发,设计,运行和运维的小应用. 这些小应用之间通过服务完成交互和集成.

微服务下的数据架构

- - IT瘾-dev
微服务是一个软件架构模式,对微服务的讨论大多集中在容器或其他技术是否能很好的实施微服务,而本文将从以下几个角度来和大家分享在微服务架构下进行数据设计需要关注的地方,旨在帮助大家在构建微服务架构时,提供一个从数据方面的视角:. 按照 Martin Fowler 的定义,微服务是一个软件架构模式,通过开发一系列的小型服务的方式来实现一个应用.