微服务架构统一安全认证设计与实践
Third-party application：第三方应用程序，本文中又称“客户端”（client）。
HTTP service：HTTP服务提供商，本文中简称“服务提供商”。
Resource Owner：资源所有者，本文中又称“用户”（user），即登录用户。
User Agent：用户代理，本文中就是指浏览器。
Authorization server：认证服务器，即服务提供商专门用来处理认证的服务器。
Resource server：资源服务器，即服务提供商存放用户生成的资源的服务器。它与认证服务器，可以是同一台服务器，也可以是不同的服务器。
服务端无状态：Token 机制在服务端不需要存储 session 信息，因为 Token 自身包含了所有用户的相关信息。
性能较好，因为在验证 Token 时不用再去访问数据库或者远程服务进行权限校验，自然可以提升不少性能。
支持移动设备，支持跨程序调用，Cookie 是不允许垮域访问的，而 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 标准。
授权码模式（authorization code）用在客户端与服务端应用之间授权码。
简化模式（implicit）用在移动 app 或者 web app（这些 app 是在用户的设备上的，如在手机上调起微信来进行认证授权）。不通过第三方应用程序的服务器，直接在浏览器中向认证服务器申请令牌，跳过了“授权码”这个步骤，因此得名。所有步骤在浏览器中完成，令牌对访问者是可见的，且客户端不需要认证。
密码模式（resource owner password credentials）应用直接都是受信任的（都是由一家公司开发的）密码模式中，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向“服务商提供商”索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。
客户端模式（client credentials）用在应用 API 访问客户端模式（Client Credentials Grant）指客户端以自己的名义，而不是以用户的名义，向“服务提供商”进行认证。严格地说，客户端模式并不属于 OAuth 框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求“服务提供商”提供服务，其实不存在授权问题。
作者：mar
本文为 @ 阿里巴巴中间件 创作并授权 21CTO 发布，未经许可，请勿转载。
内容授权事宜请您联系 webmaster@21cto.com或关注 21CTO 公众号。
该文观点仅代表作者本人，21CTO 平台仅提供信息存储空间服务。
评论
