共计 3924 个字符，预计需要花费 10 分钟才能阅读完成。
本文会详细描述两种通用的保障 API 安全性的办法：OAuth2 和 JSON Web Token (JWT)
假如:
- 你曾经或者正在实现 API；
- 你正在思考抉择一个适合的办法保障 API 的安全性；
JWT 和 OAuth2 比拟？
要比拟 JWT 和 OAuth2？首先要明确一点就是，这两个基本没有可比性，是两个齐全不同的货色。
- JWT 是一种认证协定 JWT 提供了一种用于公布接入令牌（Access Token), 并对公布的签名接入令牌进行验证的办法。令牌（Token）自身蕴含了一系列申明，应用程序能够依据这些申明限度用户对资源的拜访。
-
OAuth2 是一种受权框架 另一方面，OAuth2 是一种受权框架，提供了一套具体的受权机制（领导）。用户或利用能够通过公开的或公有的设置，受权第三方利用拜访特定资源。
既然 JWT 和 OAuth2 没有可比性，为什么还要把这两个放在一起说呢？理论中的确会有很多人拿 JWT 和 OAuth2 作比拟。题目里把这两个放在一起，的确有误导的意思。很多状况下，在探讨 OAuth2 的实现时，会把 JSON Web Token 作为一种认证机制应用。这也是为什么他们会常常一起呈现。
先来搞清楚 JWT 和 OAuth2 到底是干什么的～
JSON Web Token (JWT)
JWT 在规范中是这么定义的：
JSON Web Token (JWT) is a compact URL-safe means of representing claims to be transferred between two parties. The claims in a JWT are encoded as a JSON object that is digitally signed using JSON Web Signature (JWS). -RFC7519 https://tools.ietf.org/html/r…
JWT 是一种平安规范。基本思路就是用户提供用户名和明码给认证服务器，服务器验证用户提交信息信息的合法性；如果验证胜利，会产生并返回一个 Token（令牌），用户能够应用这个 token 拜访服务器上受爱护的资源。
一个 token 的例子:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ
一个 token 蕴含三局部：
header.claims.signature
了平安的在 url 中应用，所有局部都 base64 URL-safe 进行编码解决。
Header 头局部 头局部简略申明了类型 (JWT) 以及产生签名所应用的算法。
{"alg" : "AES256", "typ" : "JWT"}
Claims 申明
申明局部是整个 token 的外围，示意要发送的用户详细信息。有些状况下，咱们很可能要在一个服务器上实现认证，而后拜访另一台服务器上的资源；或者，通过独自的接口来生成 token，token 被保留在应用程序客户端（比方浏览器）应用。一个简略的申明（claim）的例子：
{"sub": "1234567890", "name": "John Doe", "admin": true}
Signature 签名
签名的目标是为了保障上边两局部信息不被篡改。如果尝试应用 Bas64 对解码后的 token 进行批改，签名信息就会生效。个别应用一个私钥（private key）通过特定算法对 Header 和 Claims 进行混同产生签名信息，所以只有原始的 token 能力于签名信息匹配。
这里有一个重要的实现细节。只有获取了私钥的应用程序（比方服务器端利用）能力齐全认证 token 蕴含申明信息的合法性。所以，永远不要把私钥信息放在客户端（比方浏览器）。
OAuth2 是什么？
相同，OAuth2 不是一个标准协议，而是一个平安的受权框架。它详细描述了零碎中不同角色、用户、服务前端利用（比方 API），以及客户端（比方网站或挪动 App）之间怎么实现互相认证。
The OAuth 2.0 authorization framework enables a third-party application to obtain limited access to an HTTP service, either on behalf of a resource owner by orchestrating an approval interaction between the resource owner and the HTTP service, or by allowing the third-party application to obtain access on its own behalf. -RFC6749 https://tools.ietf.org/html/r…
这里简略说一下波及到的基本概念。
Roles 角色 应用程序或者用户都能够是下边的任何一种角色：
- 资源拥有者
- 资源服务器
- 客户端利用
- 认证服务器
Client Types 客户端类型 这里的客户端次要指 API 的使用者。它能够是的类型：
- 公有的
- 公开的
Client Profile 客户端形容OAuth2 框架也指定了集中客户端形容，用来示意应用程序的类型：
- Web 利用
- 用户代理
- 原声利用
Authorization Grants 认证受权 认证授权代表资源拥有者受权给客户端应用程序的一组权限，能够是下边几种模式：
- 受权码
- 隐式受权
- 资源拥有者明码证书
- 客户端证书
- Endpoints 终端
OAuth2 框架须要下边几种终端：
- 认证终端
- Token 终端
- 重定向终端
从上边这些应该能够看出，OAuth2 定义了一组相当简单的标准。
应用 HTTPS 爱护用户明码
在进一步探讨 OAuth2 和 JWT 的实现之前，有必要说一下，两种计划都须要 SSL 平安爱护，也就是对要传输的数据进行加密编码。
平安地传输用户提供的私密信息，在任何一个平安的零碎里都是必要的。否则任何人都能够通过侵入私人 wifi，在用户登录的时候窃取用户的用户名和明码等信息。
一些重要的施行思考 在做抉择之前，参考一下下边提到的几点。
工夫投入OAuth2 是一个平安框架，形容了在各种不同场景下，多个利用之间的受权问题。有海量的材料须要学习，要齐全了解须要破费大量工夫。甚至对于一些有教训的开发工程师来说，也会须要大略一个月的工夫来深刻了解 OAuth2。这是个很大的工夫投入。相同，JWT 是一个绝对轻量级的概念。可能花一天工夫深刻学习一下标准规范，就能够很容易地开始具体实施。
呈现谬误的危险OAuth2 不像 JWT 一样是一个严格的标准协议，因而在施行过程中更容易出错。只管有很多现有的库，然而每个库的成熟度也不尽相同，同样很容易引入各种谬误。在罕用的库中也很容易发现一些安全漏洞。当然，如果有相当成熟、弱小的开发团队来继续 OAuth2 施行和保护，能够肯定成都上防止这些危险。
社交登录的益处 在很多状况下, 应用用户在大型社交网站的已有账户来认证会不便。如果冀望你的用户能够间接应用 Facebook 或者 Gmail 之类的账户, 应用现有的库会不便得多。
论断
做论断前，咱们先来列举一下 JWT 和 OAuth2 的次要应用场景。
JWT 应用场景
无状态的分布式 API
JWT 的次要劣势在于应用无状态、可扩大的形式解决利用中的用户会话。服务端能够通过内嵌的申明信息，很容易地获取用户的会话信息，而不须要去拜访用户或会话的数据库。
在一个分布式的面向服务的框架中，这一点十分有用。然而，如果零碎中须要应用黑名单实现长期有效的 token 刷新机制，这种无状态的劣势就不显著了。
劣势
- 疾速开发
- 不须要 cookie
- JSON 在挪动端的广泛应用
- 不依赖于社交登录
- 绝对简略的概念了解
限度
- Token 有长度限度
- Token 不能撤销
- 须要 token 有生效工夫限度(exp)
- OAuth2 应用场景
在作者看来两种比拟有必要应用 OAuth2 的场景：
外包认证服务器
上边曾经探讨过，如果不介意 API 的应用依赖于内部的第三方认证提供者，你能够简略地把认证工作留给认证服务商去做。也就是常见的，去认证服务商（比方 facebook）那里注册你的利用，而后设置须要拜访的用户信息，比方电子邮箱、姓名等。
当用户拜访站点的注册页面时，会看到连贯到第三方提供商的入口。用户点击当前被重定向到对应的认证服务商网站，取得用户的受权后就能够拜访到须要的信息，而后重定向回来。
举荐一个 Spring Boot 基础教程及实战示例：
https://github.com/javastacks…
劣势
- 疾速开发
- 施行代码量小
- 保护工作缩小
大型企业解决方案
如果设计的 API 要被不同的 App 应用，并且每个 App 应用的形式也不一样，应用 OAuth2 是个不错的抉择。
思考到工作量，可能须要独自的团队，针对各种利用开发欠缺、灵便的安全策略。当然须要的工作量也比拟大！这一点，OAuth2 的作者也指出过：
To be clear, OAuth 2.0 at the hand of a developer with deep understanding of web security will likely result is a secure implementation. However, at the hands of most developers – as has been the experience from the past two years – 2.0 is likely to produce insecure implementations. hueniverse – OAuth 2.0 and the Road to Hell
劣势
- 灵便的实现形式
- 能够和 JWT 同时应用
- 可针对不同利用扩大
