微服务架构统一安全认证设计与实践
上一篇：一个很酷的监控系统
大家好，我是顶级架构师。
当企业应用系统逐渐增多后，每个系统单独管理各自的用户数据容易形成信息孤岛，分散的用户管理模式阻碍了企业应用向平台化演进。当企业的互联网业务发展到一定规模，构建统一的标准化账户管理体系将是必不可少的，因为它是企业互联网云平台的重要基础设施，能够为平台带来统一的帐号管理、身份认证、用户授权等基础能力，为企业带来诸如跨系统单点登录、第三方授权登录等基础能力，为构建开放平台和业务生态提供了必要条件。
Third-party application：第三方应用程序，本文中又称“客户端”（client）。
HTTP service：HTTP服务提供商，本文中简称“服务提供商”。
Resource Owner：资源所有者，本文中又称“用户”（user），即登录用户。
User Agent：用户代理，本文中就是指浏览器。
Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。
随着 Restful API、微服务的兴起，基于 Token 的认证现在已经越来越普遍。Token 和 Session ID 不同，并非只是一个 key。Token 一般会包含用户的相关信息，通过验证 Token 就可以完成身份校验。
基于 Token 认证的优势如下：
服务端无状态：Token 机制在服务端不需要存储 session 信息，因为 Token 自身包含了所有用户的相关信息。
性能较好，因为在验证 Token 时不用再去访问数据库或者远程服务进行权限校验，自然可以提升不少性能。
支持移动设备，支持跨程序调用，Cookie 是不允许垮域访问的，而 Token 则不存在这个问题。
基于 Token 认证的一个典型流程如下：
用户输入登录信息（或者调用 Token 接口，传入用户信息），发送到身份认证服务进行认证（身份认证服务可以和服务端在一起，也可以分离，看微服务拆分情况了）。
身份验证服务验证登录信息是否正确，返回接口（一般接口中会包含用户基础信息、权限范围、有效时间等信息），客户端存储接口，可以存储在 Session 或者数据库中。
客户端将 Token 放在 HTTP 请求头中，发起相关 API 调用。
被调用的微服务，验证 Token 权限。
服务端返回相关资源和数据。
安全认证功能点：
获取凭证，第三方应用客户端使用客户端编码/安全码、资源所有者用户名/密码等证件信息从授权服务器上获取 Access Token 资源访问凭证。
登录授权，客户端携带 Access Token 凭证访问服务器资源，资源服务器验证 Token、第三方应用凭证信息、资源所有者 User 合法性，通过 Token 读取资源所有者身份信息（user）加载资源所有者的权限项执行登录。
访问鉴权，第三方应用客户端访问服务端资源，系统验证访问者 Access Token 合法性、权限信息，验证凭证（Access Token）正确，此时资源服务器就会返回资源信息。
凭证续约，Access token 访问凭证过期需要进行凭证续约，刷新 Token 凭证有效期。
系统授权采用 OAuth2 开放式授权标准密码模式。
Token 采用 JWT 标准。
OAuth 开放授权
OAuth（Open Authorization，开放授权）是为用户资源的授权定义了一个安全、开放及简单的标准，第三方无需知道用户的账号及密码，就可获取到用户的授权信息。另外，搜索公众号Java架构师技术后台回复“Spring”，获取一份惊喜礼包。
主要的四种授权方式：
授权码模式（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 凭证。
最后给读者整理了一份BAT大厂面试真题，需要的可扫码回复“面试题”即可获取。
「顶级架构师」建立了读者架构师交流群，大家可以添加小编微信进行加群。欢迎有想法、乐于分享的朋友们一起交流学习。
扫描添加好友邀你进架构师群，加我时注明【姓名+公司+职位】
版权申明：内容来源网络，版权归原作者所有。如有侵权烦请告知，我们会立即删除并表示歉意。谢谢。
猜你还想看
十几亿用户中心系统，ES+Redis+MySQL架构就轻松搞定！