[译] 深刻 OAuth2.0 和 JWT

原文连接： uriotnews.com/?s=oauth2.0…

I. 认证和受权

从基于计算机的应用出现伊始，几乎每一个开发者在其职业生涯内都会面对的一个最多见也是最复杂的问题，就是安全性（security）。这类问题意味着要考虑理解由谁提供什么数据/信息，此外还有关乎时间、校验、再校验等诸如此类的不少其余方面的事情。

而和安全性相关的全部关注点均可以被分解成两类问题：认证（Authentication） 和 受权（Authorization）。

虽然这两个术语经常交替着使用，但它们本质上表示了不一样的功用。让咱们试着擦亮记忆，再一次来定义这些概念。

认证

认证是这样一种验证过程：经过让用户、网站、应用程序经过提供合法证书或验证方式，以证实他们符合本身所宣称的身份。认证常常经过用户名和密码证明，有事也会辅以一些其余的只为用户所知的信息。这类信息或元素称为因子（factors）。基于这些因子，任何认证机制均可以划分为如下三类：

1. 单因子认证: 只依赖用户名和密码
2. 双因子认证: 除了用户名和密码，也须要一块保密信息（好比银行网站可能要求用户输入一个只有本身知道的 PIN）
3. 多因子认证 (MFA): 使用两个或多个、来自不一样类别的安全性因子（如医院系统须要用户名密码 + 用户智能手机收到的安全验证码 + 指纹信息）

受权

受权指的是一个验证某用户能访问什么的过程。在受权过程当中，某用户/应用程序的权限级别被肯定后，才被容许访问特定的 APIs/模块。一般，受权发生在用户身份被 认证 以后。

受权是经过使用“策略（policies）”和“规则（rules）”来实现的。

认证 vs 受权

虽然认证和受权经常交替着使用，但能够试着用一个“苏打水和鸡尾酒”的比喻来理解：两者殊为不一样 -- 苏打水做为一种原材料，能够被用来制做多种不一样的饮料，也能够单独饮用；而鸡尾酒则是一种由多种成分构成的混合品，苏打水也多是其中之一，但不会只包含这一种。

如此说来，说苏打水等同于鸡尾酒或鸡尾酒就是冒泡的苏打水都是不正确的。类似的是，认证和受权也不是一样的术语；实现得好的话它们能够相得益彰，但本质上是不一样的。

	认证	受权
1	肯定用户所宣称的身份	肯定用户可访问的权限
2	经过合法凭证校验用户	经过规则和策略校验访问
3	早于受权	在认证成功后执行
4	经过 ID tokens 实现	用 Access Tokens 实现

在真实场景中，要结合使用认证和受权以保护资源。当你能证实本身的身份以前，不该该被容许访问资源；而即便证实了身份，若无访问权限，依然应被拒绝。

实现机制

要实现认证和受权有多种途径，但时下最流行的是 “基于令牌（token-based）” 的方法。

什么是基于令牌的认证？

基于令牌的认证和受权（Token-based authentication/authorization）是这样一种技术：当用户在某处输入一次其用户名和密码后，做为交换会获得一个惟一辈子成的已加密令牌。该令牌随后会替代登录凭证，用以访问受保护的页面或资源。

这种方式的要点在于确保每一个发往服务器的请求都伴随着一个已签名的令牌，服务器利用该令牌核验真实性以后才对当次请求作出响应。

令牌是什么？

一个“令牌”就是服务器生成的一段数据，包含了惟一性识别一个用户的信息，通常被生成为一长串随机字符和数字。

好比看起来可能像这样：cc7112734bbde748b7708b0284233419 ，或更复杂些好比： eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJtZXNzYWdlIjoiSldUIFJ1bGVzISIsImlhdCI6MTQ1OTQ0ODExOSwiZXhwIjoxNDU5NDU0NTE5fQ.\-yIVBD5b73C75osbmwwshQNRC7frWUYrqa TjTpza2y4。

这个令牌自己是无心义和无用的，但结合适当的令牌化系统，就会变成保证应用安全性的重要一环。

为什么要使用令牌？

比之于传统的 cookies 等手段，使用令牌有以下好处：

• 无状态：令牌是自包含（self-contained）的，其包含了全部用于认证的信息。这对于可扩展性是极佳的，可让服务器从不得不存储 session 的境地中解脱
• 能够在任何地方生成：令牌的生成和校验是解耦的，让使用单独的服务器甚至不一样的厂商来完成令牌的签名成为了可能的选项，如 Auth0（译注：一家 ‘Identity-as-a-service’ 提供商）
• 细粒度的访问控制：经过令牌负荷（token payload），不只是用户可访问的资源这一项，也能够轻易制定更多用户角色和权限

基于令牌的实现

尽管具体实现各有不一样，但基本上都涉及如下步骤：

1. 用户经过用户名和密码请求访问
2. 应用验证凭证
3. 应用向客户端发放已签名的令牌
4. 客户端存储令牌，并将其附加在其后的每次请求中一同发送
5. 服务器验证令牌并响应数据

虽然说并没有关于该如何实现你的应用的限制，但 IETF（Internet Engineering Task Force，互联网工程任务组） 仍是定义了一些标准。其中最流行的有两个：

1. OAuth 2.0 (RFC 6749 and RFC 6750).

2. JWT (RFC 7519).

II. 了解 OAuth 2.0

咱们已经刷新了关于认证和受权的认知，并将了解基于令牌认证的常识。在本章节中，来看看最经常使用的一种实现：OAuth 2.0。

OAuth 2.0 简介

在传统 C/S 模型中，客户端（client）经过让服务器认证资源拥有者（resource owner）的凭证来请求服务端受保护的资源。资源拥有者会将本身的凭证分享给第三方应用（third-party applications），让后者得以访问受限资源。这种凭证分享行为会形成若干问题和限制，其中的一些以下所列：

• 第三方应用须要存储资源拥有者的凭证以持续利用，典型的如存储一个明文的密码
• 尽管存在密码固有的安全性弱点，服务器仍得支持密码认证
• 对于资源拥有者的受限资源，第三方应用获得了过于宽泛的访问权限；置资源拥有者于无力约束访问时长或限制访问资源子集的境地
• 资源拥有者没法撤回个别第三方的访问权限，除非改变全部第三方的密码

OAuth 针对这些问题提出了引入一个认证层，并把客户端（client）的角色与资源拥有者的角色分离开来。因此：

OAuth 是一种受权协议，以容许用户将对其在一个站点上的资源的受限访问许可给另外一个站点，而没必要公开其凭据

OAuth 为客户端提供一种“安全代理访问”能力，用以表明资源拥有者访问服务器资源。OAuth 指定了这样一个过程：资源拥有者在不分享其凭证的前提下受权第三方访问其服务器资源。

下面举个例子来讲明：

泊车钥匙

你知道有些小轿车的“泊车钥匙”吧？若是还不曾耳闻的话，那就是有些车型（没错，就是特别奢侈的那些！）附有一种特别的钥匙，能够在泊车时交给服务员。和你的正常钥匙不一样的是，这种钥匙不容许汽车开出去一两英里那么远。

某些泊车钥匙打不开后备箱，另外一些则访问不了车载电话的通信录。不管此类限制是什么，思路都是同样清晰的：你让某人经过特殊的钥匙有限访问你的车，但你的正常钥匙能解锁一切。

相似的，OAuth 中的“泊车钥匙”就是 访问令牌（Access Tokens），经过其容许对资源的不一样级别的访问。

OAuth 2.0 术语

角色（Roles）： OAuth2.0 规范定义了四种角色。

1. 资源拥有者 Resource Owner：一个有能力对访问受保护资源受权的实体（entity）。当这个实体是一我的时，它就表示终端用户（end-user）。
2. 资源服务器 Resource Server： 存储受保护资源的服务器，能接受和响应使用访问令牌的受保护资源请求。
3. 客户端 Client：一个发起对受保护资源请求的应用程序，其表明了资源拥有者并持有其凭证。术语 “client” 并不意味着任何实现特征（如该应用程序是否运行在服务器上、桌面端，或是其余设备上）。
4. 受权服务器 Authorization Server：当资源拥有者认证成功并得到受权以后，该服务器向客户端授予访问令牌。

令牌（Tokens）： 令牌有两种类型。

1. 访问令牌 Access Token： 访问令牌即表示颁发给客户端之受权的一个字符串。对用户端来讲这个字符串通常是晦涩的。令牌表明了特殊的访问范围和持续时间，由资源拥有者授予，被资源服务器和受权服务器实施。

   令牌可能表示一个用来取回认证信息的标识符，也可能以一种可验证的方式（如包含一些数据和签名）自包含认证信息。

2. 更新令牌 Refresh Token： 更新令牌是用来得到访问令牌的凭证。更新令牌由受权服务器向客户端发出，并在当访问令牌无效或过时后，用更新令牌得到一个新的访问令牌；也可能用其得到访问范围相同或更窄的附加访问令牌（这些访问令牌和通过资源拥有者受权的访问令牌相比，可能有更短的生存时间和更少的权限）。

   是否发放一个更新令牌是由受权服务器酌情处理的；若是发放了则会用在后续发放访问令牌时。

不一样于请求令牌，更新令牌专为受权服务器设计，不会发送给资源服务器。

受权许可（Authorization Grant）： 受权许但是一种表示资源拥有者之承认（访问其受保护资源）的凭证，被客户端用于获取访问令牌。OAuth 2.0 规范定义了四种许可类型：

1. 受权代码 Authorization Code: 受权代码由使用一个做为客户端和资源拥有者之中间人的受权服务器处获取。不一样于从资源拥有者那里直接请求受权，客户端将资源拥有者引导至受权服务器，后者又将资源拥有者伴随一个受权代码引导回客户端。
2. 隐式许可 Implicit Grant: 不向客户端发送受权代码，而是由客户端直接获取访问令牌。
3. 资源拥有者密码凭证 Resource owner password credentials (ROPC): 资源拥有者密码凭证（如用户名和密码）可被直接做为受权许能够获取访问令牌。ROPC 只应被使用在资源拥有者和客户端（如客户端是所在设备操做系统的一部分，或是一个高权限的应用）之间须要高信任等级，且其余几种受权许可（如受权代码）不可用的时候。
4. 客户端凭证 Client Credentials: 当受权范围限于客户端控制之下的受保护资源，或是与受权服务器事先约定的受保护资源的时候，客户端凭证（或其余客户端认证形式）可被用来做为一种受权许可。典型的是客户端表明本身（其同时也是资源拥有者）或客户端正在请求访问基于事先和资源服务器约定好的受保护资源的时候。

处理 OAuth 2.0 时理解这些术语是相当重要的。因此，也试着用一个例子来讲明。

想象一个地铁运输系统。典型的引导流程以下：一位乘客（commuter）从售票机或售票窗口购买车票，制票系统许可这张车票在有限的时间或站点数量之间是合法的。然后，乘客在闸机验票，车票合法则准许进入，便可乘坐列车。

用地铁来比喻 OAuth

以上场景能够和下面的 OAuth 2.0 中的角色对应起来：

乘客 (客户端) 打算利用地铁 (受保护的资源)，因此他/她得先向售票机或售票窗口 (资源服务器) 买票。制票系统 (受权服务器) 表明地铁部门 (资源拥有者) 以车票 (令牌) 为依据许可访问。

用地铁来比喻 OAuth

OAuth 2.0 控制流

一次 OAuth 2.0 的流程可用下图表示:

OAuth 2.0 控制流

OAuth 2.0 用例

OAuth 2.0 把认证从受权决策中解耦。恰当设计的 OAuth 2.0 令牌既能够支持细粒度受权，也能够支持粗粒度受权。对于任何从另外一处（服务器/应用）访问存储在某处的资源/数据的场景，OAuth 2.0 可说是最适用的方法之一了。

如下列出一些场景，咱们将尝试经过一个可穿戴设备的例子理解 OAuth 2.0 用例。

就拿运动手环来讲吧，假设 Alice 买了一个，并用移动端上配套的手环 app 跟踪并分析运动过程。那么流程会是什么样呢？

• 首先，Alice 须要在手环 app 中建立我的档案。一种方法是用手环 app 提供的档案建立表单，另外一种方法是让手环 app 访问其余 app 并拉取 Alice 已经存储在那里的档案信息 -- 就拿 FriendBook 这个明显是虚构的社交媒介网站来举例吧。
• 手环 app 将重定向到 FriendBook 的登陆界面。一旦 Alice 成功使用其凭证登陆，她将看到一个准许赞成的页面，询问她或请她验证她的哪些信息要分享，以及她容许访问哪些存储在 FriendBook 上的东西。在确认以后，手环 app 就可使用 OAuth 2.0 从 FriendBook 拉取并使用数据了。
• 可穿戴设备会向手环 app 发送数据，其后，手环 app 会同步数据到服务器，以期存档和分析。

客户端密码： (尽管使用了 OAuth 2.0 的认证应该被避免). Alice 没必要建立一个新密码；取而代之的是，她使用本身在 FriendBook 服务器上已经建立的密码。

Web 服务器： 可穿戴设备的 app 没必要每次操做都发起登陆。Alice 要从 FriendBook 上分享或拉取数据，手环 app 将可以以服务器对服务器的方式访问那些数据。

用户代理： 手环 app 扮演了其应用服务器的代理人的角色，用来从主服务器上同步数据。因为使用了 OAuth 2.0 对此受权，该代理能够准确访问服务器上的资源（数据）。

3. 了解 JWT

下面来看看 JWT。

JSON Web Token (JWT)，一般读做 “jot”，是一个定义了以 JSON 对象紧凑而自包含的在各方之间安全传输信息的标准。其包含了声明方面的信息，特别的被用于如 HTTP 等空间受约束的环境；该信息可被验证，也是可信的，由于通过了数字化签名。JWT 能够用 密钥（如 HMAC） 或 公钥私钥对（RSA 或 ECDSA） 签名。

JWT 的两个特性是：

• 紧凑 Compact： 由于其相对较小的尺寸，JWT 能够借由 URL 发送， 做为一个 POST 参数，或在一个 HTTP header 内。
• 自包含 Self-contained： 一个 JWT 包含了全部关于一个实体的所需信息，以免屡次查询数据库。JWT 的接纳者一样无需调用服务器以验证令牌。

这些令牌能够是被签名的、被加密的，或二者皆有。签名过的令牌被用来验证令牌完整性，而加密过的令牌用来隐藏声明。

注意：正如名称所暗示的，JWT 是 JSON 形式的，也就意味着其包含键值对。虽然说在 JSON 合法和有关方一致性方面，对键和值有多长并没有限制，但大多数标准都遵循了 3个字母 的键格式。

JWT 术语

JWT 表现为由点（.）分割的三个字符串组成的一个序列，典型的格式看起来以下：

AAAAA.BBBBB.CCCCC

三个子串分别称做 头部（Header） 、 负载（Payload） 和 签名（Signature），下面逐一讲解：

头部 Header

虽然说只要相关几方之间有共识，则在头部中放什么是没有限制的，但一般由两部分组成：

1. typ: 表示令牌类型（type），值为 JWT
2. alg: 表示签名此令牌的算法（algorithm），如 HMAC、RSA、SHA

负载 Payload

JWT 的第二部分表示负载，这部分由声明（claims）组成。

所谓声明就是关于实体和任意附加数据的信息。在一段 JWT 中，声明由键表示。这些声明是依赖上下文的，且应该相应的被处理和被理解，但依每种规范会有若干标准规则应用于声明：

1. 在一个 JWT 声明集合中，每一个声明的名称必须是惟一的
2. 对于 JWT 的处理逻辑，必须 保证这种惟一性，要么拒绝重复的名字，要么用一个 JSON 处理器返回重复项中词法上最后一个名字
3. 使用 JWT 的应用要明确其选用的声明标准，并定义必须项和可选项
4. 由于 JWT 的核心目标之一就是精简，故全部名字也应该简短

一个可能的负载例子：

{ 
    "sub": "1234567890", "name": "Alice", "admin": true
}
复制代码

负载中的声明又能够细分为如下三种类型：

已注册的声明

有一些声明注册在 IANA(dzone.com/refcardz/co…) 的 “JSON Web 令牌声明” 注册表中。这些声明并不是是在全部状况下都要求强制使用或实现的，准确的说它们是做为提供一个有用的集合的起始点而被注册的。

其中一些有必要了解的是：

1. iss (issuer): 声明了发行人，也就是发行 JWT 的主体。处理此声明一般是因应用而异的。“iss” 值是一个大小写敏感的字符串，包含一个普通字符串或者一个 URL。该声明是可选的
2. sub (subject): 表示 JWT 的主体 (用户)。值必需要么是全局惟一的，要么在发行人上下文范围内局部惟一。处理该声明一般也是因应用而异的。“sub” 值是一个大小写敏感的字符串，包含一个普通字符串或者一个 URL。该声明是可选的
3. aud (audience): 表示 JWT 的目标接收方。若是当该声明存在且处理该声明的一方不能经过 “aud” 的值进行自我身份验证时，则 JWT 必须被拒绝。大多数状况下，这个值是由大小写敏感的字符串（包含一个普通字符串或者一个 URL）组成的数组。该声明是可选的
4. exp (expiration): 表示过时时间，即等于或晚于那个时刻再处理 JWT 则毫不可被接受。其值一般是以秒记的时间戳（译注：按 POSIX 中定义的 “seconds since epoch” 标准，也就是 PHP 等语言中经常使用的那种）。该声明是可选的
5. nbf (not before) : 表示一个时间，即早于那个时刻再处理 JWT 则毫不可被接受。 其值一般是以秒记的时间戳。该声明是可选的
6. iat (issued at): 表示发出 JWT 的时刻。可用于判断 JWT 的寿命。必须是一个时间戳。该声明是可选的
7. jti (JWT ID): 为 JWT 提供一个惟一的身份识别符，其值必须难以重复，以防 JWT 被重复执行。该声明是可选的

公开声明

此类声明的名字可被 JWT 使用者任意定义。但为了预防冲突，任何新名字都应该注册在 IANA “JSON Web Token Claims” 注册表中，或将其定义为包含防冲突命名空间的 URI 等。

在任何状况下，对名字和值的定义都要考虑到合理的预防措施，以确保它们在其定义的命名空间中受控。

私有声明

这能够理解为是建立自定义声明以在应用内共享信息规格，能够是除以上两种外的任意声明名字。与公有声明不一样，私有声明受制于冲突问题，要当心使用。

签名

签名先是经过对头部和负载 Base64 编码而生成，其后会与一个密钥联合，最好被头部中指定的算法签名。

签名被用于校验 JWT 的发送者是否名实相符，以及信息在传送过程当中是否被更改。好比，若是建立了一个使用 HMAC SHA256 算法之令牌的签名，你会像下面这样作：

HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret)
复制代码

一个更完整的例子

观察以下 JWT 签名：

eyJhbGciOiJIUzUxMiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiJzYXRpc2giLCJhdWQiOiJteWFwcCIsIkNVU1QiOiIxIiwiZXhwIjoxNTY2MjE0NTg1LCJpc3MiOiJhdXRoLWFwcCJ9.WknG6jiM_vAaflLnKyjlXh5BrM4MUJR9dFrVx-XE3zRVWiyXeIVzI-OomFh0vVHRwrK3-Tttg0HyKBTnCA3mSg
复制代码

该签名使用了 HS512 算法编码，并包含了以下信息：

Header: { 
    "alg": "HS512", 
    "typ": "JWT"
} 
Payload: { 
    "sub": "satish", 
    "aud": "myapp", 
    "CUST": "1", 
    "exp": 1566214585, 
    "iss": "my-auth-app"
}
复制代码

JWT 用例

认证

当用户使用其凭证成功登陆后，一个 ID 令牌会被返回。按照 OpenID Connect (OIDC) 规范，该 ID 令牌就是一个 JWT。

受权

一旦用户登陆成功，应用就可能会表明用户请求访问路由、服务、资源等。为此，将使用一个访问令牌，形式上可能就是 JWT。每一个后续的请求也都包含该访问令牌。因为 JWT 开销很小，也能轻易用于跨域名访问，单点登陆（SSO，Single Sign-on）普遍使用这项技术。

信息交换

因为可被签名，JWT 是一种在多方间安全传递信息的良好方式，这意味着你能肯定发送者名实相符。另外，一个 JWT 结构容许你验证内容没有被篡改过。

为什么使用 JWT ？

解耦

JWT 最大的优点（比之于使用内存内随机令牌的用户 session 管理）就是其使得对第三方服务器认证逻辑的代理能够：

• 一个集中式的、内部自定义开发的认证服务器
• 更典型的是，使用 LDAP 这种能够发出 JWT 的商业产品
• 甚至可使用一个纯第三方的认证提供商

认证逻辑/服务器能够从应用服务器彻底分离，无需在应用间再分享密码摘要。

无状态

因为 JWT 是自包含的，且无需在内存中保持请求之间的令牌，因此应用服务器能够作到彻底无状态（stateless）。认证服务器能够颁发令牌，将其发回后就当即丢弃掉。

紧凑

JSON 比 XML 简介，因此当其被编码后，一个 JWT 比 SAML 令牌更小。这使得 JWT 成为一个在 HTML 和 HTTP 环境中传送的好选择。

更安全

为了签名，JWT 可使用一个公钥/私钥对，表现为 X.509 证书的形式。一个 JWT 也能够经过分享使用了 HMAC 算法的密钥而被对称签名。同时虽然 SAML 令牌也可使用 JWT 这样的公钥/私钥对，但相比于签名 JSON 的简单性，想用 XML 数字签名算法签名 XML 却不会引入未知的安全漏洞是很是困难的。

更通用

由于直接映射到对象，JSON 处理器在大多数编程语言中都更常见。相反，XML 没有天然的 文档到对象 的映射。这意味着 JWT 比 SAML 更易用。

更易处理

JWT 为互联网规模而设计，意思就是其在用户设备上更易处理，特别是移动端。

JWT：要考虑到的点

除去以上说过的优缺点，JWT 标准也有其自身的问题：

• 若是须要封锁或冻结一个用户帐号，应用就不得不等待令牌过时才能彻底停工。
• 若是用户要更新密码（例如在帐户劫持的状况下）且一个认证在以前已经被执行过的话，那么由以前的密码产生的令牌会在过时前持续有效。
• 在标准实现中，没有“更新”令牌被指定。所以过时后用户将从新认证。
• 在不违背 JWT 令牌的“无状态”方面的前提下，是不可能破坏一个令牌的，即使令牌已从浏览器被删除，它也会在过时前一直有效。

为了应对这些调整，一些 JWT 库在标准实现之上增长了一个层，并容许更新令牌机制，同时也包含一些特性如在必要状况下强制用户从新认证等。

JWT：最佳实践

在动手实现 JWT 以前，让咱们了解一些最佳实践，以确保基于令牌的认证恰当地用于你的应用中。

1. 保证安全。签名 key 应该同其余任何凭证同样被处理，并只出示给必须须要它的服务。
2. 不要在负载中加入敏感信息。令牌被签名为难操做易解码的形式。向负载中添加最少的声明以保证性能和安全性。
3. 给令牌设置过时时间。技术上来讲，一旦令牌被签名 -- 它就是永久有效的，除非用来签名的 key 改变，或明确的设置了过时时间。这会形成隐患，因此应该有令牌的过时、撤销策略。
4. 拥抱 HTTPS。不要向非 HTTPS 的链接发送令牌，由于那些请求能够被拦截从而连累到令牌。
5. 考察你全部的受权用例。增长一个次要的令牌验证系统以确保令牌能从你的服务器上生成，举例来讲，也许不是通用作法，但可能对实现需求是很必要的。

更多

用 Spring Boot 2 和 JWT 实现基于角色的访问控制

--End--

搜索 fewelife 关注公众号

转载请注明出处