关于分布式系统:分布式系统如何实现用户追踪和认证

世界上最快的捷径，就是好高鹜远，本文已收录【架构技术专栏】关注这个喜爱分享的中央。

在一些互联网公司的面试中，面试官往往会问这样一个问题：

如果禁用浏览器 cookie，如何实现用户追踪和认证？

遗憾的是仍然有大量候选人答非所问，无奈搞清楚 cookie 和 session 之间的区别。

而在工作中也有让人诧异的实在案例：

把 user ID 存储到 local storage 中当做 token 应用，起因是他们宣称弃用了 cookie 这种落后的货色；

一个挪动端我的项目，服务器给出的 API 中须要客户端模仿一个 cookie，从而像浏览器中 ajax 那样生产 API。

互联网是基于 HTTP 协定构建的，而 HTTP 协定因为简略风行开来，然而 HTTP 协定是无状态（通信层面上虚电路比数据报低廉太多）的，为此人们为了追踪用户想出了各种方法，包含 cookie/session 机制、token、flash 跨浏览器 cookie 甚至浏览器指纹等。

把用户身份藏在每一个中央（浏览器指纹技术甚至不须要存储介质）

讲应用 spring security 等具体技术的材料曾经很多了，这篇文章不打算写框架和代码的具体实现。

咱们会探讨认证和受权的区别，而后会介绍一些被业界宽泛采纳的技术，最初会聊聊怎么为 API 构建抉择适合的认证形式。

认证、受权、凭证

首先，认证和受权是两个不同的概念，为了让咱们的 API 更加平安和具备清晰的设计，了解认证和受权的不同就十分有必要了，它们在英文中也是不同的单词。

认证（authentication）

指的是以后用户的身份，当用户登陆过后零碎便能追踪到他的身份做出合乎相应业务逻辑的操作。

即便用户没有登录，大多数零碎也会追踪他的身份，只是当做来宾或者匿名用户来解决。

认证技术解决的是“我是谁？”的问题。

受权是 (authorization)

指的是什么样的身份被容许拜访某些资源，在获取到用户身份后持续检查用户的权限。

繁多的零碎受权往往是随同认证来实现的，然而在凋谢 API 的多系统结构下，受权能够由不同的零碎来实现，例如 OAuth。

受权技术是解决“我能做什么？”的问题。

凭证

实现认证和受权的根底是须要一种媒介（credentials）来标记访问者的身份或权力，在现实生活中每个人都须要一张身份证能力拜访本人的银行账户、结婚和办理养老保险等，这就是认证的凭证；

在现代军事流动中，皇帝会给出战的将军颁发兵符，上级将领不关怀持有兵符的人，只须要执行兵符对应的命令即可。

在互联网世界中，服务器为每一个访问者颁发 session ID 寄存到 cookie，这就是一种凭证技术。数字凭证还体现在方方面面，SSH 登录的密匙、JWT 令牌、一次性明码等。

举例

用户账户也不肯定是寄存在数据库中的一张表，在一些企业 IT 零碎中，对账户治理和权限有了更多的要求。

所以账户技术（accounting）能够帮忙咱们应用不同的形式治理用户账户，同时具备不同零碎之间共享账户的能力。

例如微软的流动目录（AD），以及简略目录拜访协定（LDAP），甚至区块链技术。

拜访控制策略（AC）

还有一个重要的概念是拜访控制策略（AC）。

如果咱们须要把资源的权限划分到一个很细的粒度，就不得不思考用户以何种身份来拜访受限的资源，抉择基于访问控制列表（ACL）还是基于用户角色的访问控制（RBAC）或者其余拜访控制策略。

在风行的技术和框架中，这些概念都无奈孤立的被实现，因而在事实中应用这些技术时，大家往往为一个 OAuth2 是认证还是受权这种概念争论不休。

为了容易了解，我在文末附上了一份常见技术和概念的术语表。

上面我会介绍在 API 开发中经常应用的几种认证和受权技术：

• HTTP Basic AUthentication
• HAMC、OAuth2
• JWT token。

HTTP Basic Authentication

你肯定用过这种形式，但不肯定晓得它是什么，在不久之前，当你拜访一台家用路由器的治理界面，往往会看到一个浏览器弹出表单，要求你输出用户明码。

在这背地，当用户输出完用户名明码后，浏览器帮你做了一个非常简单的操作:

组合用户名和明码而后 Base64 编码

给编码后的字符串增加 Basic 前缀，而后设置名称为 Authorization 的 header 头部

API 也能够非常简单的提供 HTTP Basic Authentication 认证形式，那么客户端能够很简略通过 Base64 传输用户名和明码即可:

• 将用户名和明码应用冒号连贯，例如 username:abc123456
• 为了避免用户名或者明码中存在超出 ASCII 码范畴的字符，举荐应用 UTF- 8 编码
• 将下面的字符串应用 Base 64 编码，例如 dXNlcm5hbWU6YWJjMTIzNDU2
• 在 HTTP 申请头中退出“Basic + 编码后的字符串”，即：Authorization: Basic QWxhZGRpbjpPcGVuU2VzYW1l

这种形式实现起来非常简单，在大量场景下被采纳。

当然毛病也很显著，Base64 只能称为编码，而不是加密 (实际上无需配置密匙的客户端并没有任何牢靠地加密形式，咱们都依赖 TSL 协定)。

这种形式的致命弱点是编码后的明码如果明文传输则容易在网络传输中泄露，在明码不会过期的状况下，明码一旦泄露，只能通过批改明码的形式。

HMAC（AK/SK）认证

在咱们对接一些 PASS 平台和领取平台时，会要求咱们事后生成一个 access key（AK）和 secure key（SK），而后通过签名的形式实现认证申请，这种形式能够防止传输 secure key，且大多数状况下签名只容许应用一次，防止了重放攻打。

这种基于 AK/SK 的认证形式次要是利用散列的音讯认证码 (Hash-based MessageAuthentication Code) 来实现的，因而有很多中央叫 HMAC 认证，实际上不是十分精确。

HMAC 只是利用带有 key 值的哈希算法生成音讯摘要，在设计 API 时有具体不同的实现。

HMAC 在作为网络通信的认证设计中作为凭证生成算法应用，防止了口令等敏感信息在网络中传输。

根本过程如下：

1. 客户端须要在认证服务器中事后设置 access key（AK 或叫 app ID）和 secure key（SK）
2. 在调用 API 时，客户端须要对参数和 access key 进行天然排序后并应用 secure key 进行签名生成一个额定的参数 digest
3. 服务器依据事后设置的 secure key 进行同样的摘要计算，并要求后果完全一致
4. 留神 secure key 不能在网络中传输，以及在不受信赖的地位寄存（浏览器等）

为了让每一次申请的签名变得举世无双，从而实现重放攻打，咱们须要在签名时放入一些烦扰信息。

在业界规范中有两种典型的做法:

• 质疑 / 应答算法（OCRA: OATH Challenge-Response Algorithm）
• 基于工夫的一次性明码算法（TOTP：Time-based One-time Password Algorithm）

质疑 / 应答算法

质疑 / 应答算法须要客户端先申请一次服务器，取得一个 401 未认证的返回，并失去一个随机字符串（nonce）。

将 nonce 附加到依照下面说到的办法进行 HMAC 签名，服务器应用事后调配的 nonce 同样进行签名校验，这个 nonce 在服务器只会被应用一次，因而能够提供惟一的摘要。

基于工夫的一次性明码认证

为了防止额定的申请来获取 nonce，还有一种算法是应用工夫戳，并且通过同步工夫的形式协商到统一，在肯定的工夫窗口内无效（1 分钟左右）。

这里的只是利用工夫戳作为验证的工夫窗口，并不能严格的算作基于工夫的一次性明码算法。

规范的基于工夫的一次性明码算法在两步验证中被大量应用，例如 Google 身份验证器不须要网络通信也能实现验证（但依赖精确的授时服务）。

原理是客户端服务器共享密钥而后依据工夫窗口能通过 HMAC 算法计算出一个雷同的验证码。

TOTP 基本原理和常见厂商

OAuth2 和 Open ID

OAuth（凋谢受权）是一个凋谢规范，容许用户受权第三方网站拜访他们存储在另外的服务提供者上的信息，而不须要将用户名和明码提供给第三方网站或分享他们数据的所有内容。

OAuth 是一个受权规范，而不是认证规范。提供资源的服务器不须要晓得确切的用户身份（session），只须要验证受权服务器授予的权限（token）即可。

上图只是 OAuth 的一个简化流程，OAuth 的基本思路就是通过受权服务器获取 access token 和 refresh token（refresh token 用于从新刷新 access token），而后通过 access token 从资源服务器获取数据。

在特定的场景下还有上面几种模式：

• 受权码模式（authorization code）
• 简化模式（implicit）
• 明码模式（resource owner password credentials）
• 客户端模式（client credentials）

如果须要获取用户的认证信息，OAuth 自身没有定义这部分内容，如果须要辨认用户信息，则须要借助另外的认证层，例如 OpenID Connect。

验证 access token

OAuth 验证

在一些介绍 OAuth 的博客中很少讲到资源服务器是怎么验证 access token 的。

OAuth core 规范并没有定义这部分，不过在 OAuth 其余标准文件中提到两种验证 access token 的形式,

在实现受权流程后，资源服务器能够应用 OAuth 服务器提供的 Introspection 接口来验证 access token，OAuth 服务器会返回 access token 的状态以及过期工夫。

在 OAuth 规范中验证 token 的术语是 Introspection。

同时也须要留神 access token 是用户和资源服务器之间的凭证，不是资源服务器和受权服务器之间的凭证。

资源服务器和受权服务器之间应该应用额定的认证（例如 Basic 认证）。

JWT 验证

受权服务器应用私钥签发 JWT 模式的 access token，资源服务器须要应用事后配置的公钥校验 JWT token，并失去 token 状态和一些被蕴含在 access token 中信息。

因而在 JWT 的计划下，资源服务器和受权服务器不再须要通信，在一些场景下带来微小的劣势。

同时 JWT 也有一些弱点，我会在 JWT 的局部解释。

refresh token 和 access token

简直所有人刚开始理解 OAuth 时都有一个一疑难，为什么曾经有了 access token 还须要 refresh token 呢？

受权服务器会在第一次受权申请时一起返回 access token 和 refresh token，在前面刷新 access token 时只须要 refresh token。

access token 和 refresh token 的设计用意是不一样的，access token 被设计用来客户端和资源服务器之间交互，而 refresh token 是被设计用来客户端和受权服务器之间交互。

某些受权模式下 access token 须要裸露给浏览器，充当一个资源服务器和浏览器之间的长期会话，浏览器和资源服务器之间不存在签名机制，access token 成为惟一凭证，因而 access token 的过期工夫（TTL）应该尽量短，从而防止用户的 access token 被嗅探攻打。

因为要求 access token 工夫很短，refresh token 能够帮忙用户保护一个较长时间的状态，防止频繁从新受权。

大家会感觉让 access token 放弃一个长的过期工夫不就能够了吗？

实际上 refresh token 和 access token 的不同之处在于即便 refresh token 被截获，零碎仍然是平安的，客户端拿着 refresh token 去获取 access token 时同时须要事后配置的 secure key，客户端和受权服务器之前始终存在平安的认证。

OAuth、Open ID、OpenID Connect

认证方面的术语切实太多，我在搭建本人的认证服务器或接入第三方认证平台时，有时候到实现开发工作的最初一刻都无奈了解这些术语。

OAuth

OAuth 负责解决分布式系统之间的受权问题，即便有时候客户端和资源服务器或者认证服务器存在同一台机器上。

OAuth 没有解决认证的问题，但提供了良好的设计利于和现有的认证零碎对接。

Open ID

Open ID 解决的问题是分布式系统之间身份认证问题，应用 Open ID token 能在多个零碎之间验证用户，以及返回用户信息，能够独立应用，与 OAuth 没有关联。

OpenID Connect

OpenID Connect 解决的是在 OAuth 这套体系下的用户认证问题，实现的基本原理是将用户的认证信息（ID token）当做资源解决。

在 OAuth 框架下实现受权后，再通过 access token 获取用户的身份。

这三个概念之间的关系有点难以了解，用事实场景来说，如果零碎中须要一套独立的认证零碎，并不需要多零碎之间的受权能够间接采纳 Open ID。如果应用了 OAuth 作为受权规范，能够再通过 OpenID Connect 来实现用户的认证。

JWT

在 OAuth 等分布式的认证、受权体系下，对凭证技术有了更多的要求，比方蕴含用户 ID、过期等信息，不须要再内部存储中关联。

因而业界对 token 做了进一步优化，设计了一种自蕴含令牌，令牌签发后无需从服务器存储中查看是否非法，通过解析令牌就能获取令牌的过期、无效等信息，这就是 JWT（JSON Web Token）。

JWT 是一种蕴含令牌（self-contained token），或者叫值令牌（value token），咱们以前应用关联到 session 上的 hash 值被叫做援用令牌（reference token）。

简而言之，一个根本的 JWT 令牌为一段点分 3 段式构造。

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ

生成 JWT 令牌的流程为:

header json 的 base64 编码为令牌第一局部

payload json 的 base64 编码为令牌第二局部

拼装第一、第二局部编码后的 json 以及 secret 进行签名的令牌的第三局部

因而只须要签名的 secret key 就能校验 JWT 令牌，如果在音讯体中退出用户 ID、过期信息就能够实现验证令牌是否无效、过期了，无需从数据库 / 缓存中读取信息。

因为应用了加密算法，所以第一、二局部即便被批改（包含过期信息）也无奈通过验证。

JWT 长处是不仅能够作为 token 应用，同时也能够承载一些必要信息，省去屡次查问。

留神：

• JWT token 的第一、二局部只是 base64 编码，肉眼不可读，不该当寄存敏感信息
• JWT token 的自蕴含个性，导致了无奈被撤回
• JWT 的签名算法能够本人拟定，为了便于调试，本地环境能够应用对称加密算法，生产环境倡议应用非对称加密算法
• JWT token 在微服务的零碎中劣势特地突出。多层调用的 API 中能够间接传递 JWT token，利用自蕴含的能力，能够缩小用户信息查问次数；更重要的是，应用非对称的加密形式能够通过在零碎中散发密匙的形式

验证 JWT token。

当然 OAuth 对 access token 等凭证所选用的技术并没有做出限度，OAuth 并不强制应用 JWT，在应用 JWT 自蕴含个性的劣势时，必须思考到 JWT 撤回艰难的问题。

在一些对撤回 token 要求很高的我的项目中不适宜应用 JWT，即便采纳了一些计划实现（whitelist 和 blacklist）也违反了设计 JWT 的初衷。

Cookie、Token in Cookie、Session Token 仍然被应用

在构建 API 时，开发者会发现咱们的认证形式和网页利用有一些不同，除了像 ajax 这种典型的 web 技术外，如果咱们心愿 API 是无状态的，不举荐应用 Cookie。

应用 Cookie 的实质是用户第一次拜访时服务器会调配一个 Session ID，前面的申请中客户端都会带上这个 ID 作为以后用户的标记，因为 HTTP 自身是无状态的，Cookie 属于一种内建于浏览器中实现状态的形式。

如果咱们的 API 是用来给客户端应用的，强行要求 API 的调用者治理 Cookie 也能够实现工作。

在一些遗留或者不是规范的认证实现的我的项目中，咱们仍然能够看到这些做法，疾速地实现认证。

应用 cookie，例如 web 我的项目中 ajax 的形式

应用 session ID 或 hash 作为 token，但将 token 放入 header 中传递

将生成的 token（可能是 JWT）放入 cookie 传递，利用 HTTPonly 和 Secure 标签爱护 token

抉择适合的认证形式

随着微服务的倒退，API 的设计不仅仅是面向 WEB 或者 Mobile APP，还有 BFF（Backend for Frontend）和 Domain API 的认证，以及第三方服务的集成。

客户端到服务器之间认证和服务器到服务器之间认证是不同的。

咱们把终端用户（Human）参加的通信，叫做 Human-to-machine (H2M)，服务器与服务器之间的通信叫做 Machine-to-machine (M2M)。

H2M 的通信须要更高的安全性，M2M 的通信人造比 H2M 平安，因而更多的强调性能，在不同的场合下抉择适合的认证技术就显得特地重要。

例如 HTTP Basic Authentication 用来作为 H2M 认证显得有些落后，然而在 M2M 中被大量应用。

另外值得一提的是，H2M 这种通信形式下，客户端不受管制，因为无奈自主散发密匙，认证通信的平安高度依赖 HTTPS。

从一个宏观的角度对待他们的关系，对咱们技术选型十分有帮忙。

术语表

Browser fingerprinting

通过查问浏览器的代理字符串，屏幕色深，语言等，而后这些值通过散列函数传递产生指纹，不须要通过 Cookie 就能够辨认浏览器

MAC（Message authentication code

在密码学中，讯息甄别码，是通过特定算法后产生的一小段资讯，查看某段讯息的完整性

HOTP（HMAC-based One-time Password algorithm

基于散列音讯验证码的一次性明码算法

Two-step verification

是一种认证办法，应用两种不同的元素，合并在一起，来确认使用者的身份，是多因素验证中的一个特例

OTP（One time password）

一次性明码，例如注册邮件和短信中的认证码