OAuth2 vs JWT，到底怎么选？
本文将详细介绍两种常用的方法来确保API的安全性：OAuth2和JSON Web Token（JWT）。
假设:
- 您已或正开发API；
- 您正评估和选择适当的安全措施以确保其安全性；
JWT和OAuth2比较？
在比较JWT与OAuth2两种技术时，请首先明确它们之间没有任何共同之处
- JSON Web Token（JWT）是一种广泛采用的认证协议。该协议允许开发者通过发布带有访问令牌的信息来实现身份验证。
- Open Access Tokens (OAuth2) 是一种流行的权威化架构,为开发者提供了详细的授权管理机制。
- 用户或应用可以通过公开的或私有的设置来配置其权限范围,允许开发者根据需要选择公开或私有的方式配置应用权限。
- 将两个方案放在一起介绍可能会误导读者,因为它们本质上无法直接比较。
- 在实际应用中讨论 OAuth2 实现时经常涉及与 JWT 的结合使用情况,这也是两者常被提及的原因之一。
先来搞清楚JWT和OAuth2究竟是干什么的～
JSON Web Token (JWT)
JWT在标准中是这么定义的：
在数字身份认证领域中扮演着重要角色的JSON Web Token (JWT)，是一种经过精心设计的URL安全机制，在交换于两个实体之间的声明中发挥着关键作用。
这些声明在JWT中被编码为一个JSON对象，并通过数字签名技术（JWS）进行加密。
-RFC7519 https://tools.ietf.org/html/rfc7519
JSON Web Token（JWT）是一种广泛采用的安全标准。其核心流程在于用户向认证服务器提交用户名和密码以验证所提交的信息合法性和真实性；当验证成功时会生成并返回一个Token（即令牌），这些Token则可被用于允许用户通过此认证机制访问服务器上受保护的资源。
一个token的例子:
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ一个token包含三部分：
header.claims.signature了安全的在url中使用，所有部分都 base64 URL-safe进行编码处理。
Header头部分 头部分简单声明了类型(JWT)以及产生签名所使用的算法。
{ "alg" : "AES256", "typ" : "JWT"}Claims声明
声明字段是整个token的核心组成部分，在某些情况下我们需要在一个服务器上完成身份验证操作，并让该服务器调用另一个服务器上的资源；或者通过独立接口生成tokens并将这些tokens保存在客户端（例如浏览器）中供其使用。举个简单的例子，在JSON格式中我们会包含一个"username"字段和一个"password"字段这两个字段共同构成了一个"claims"数组中的单个"claim"元素
{ "sub": "1234567890", "name": "John Doe", "admin": true}Signature签名
该方法的主要目的旨在防止上下文中任意两部分信息被同时篡改或损坏。在尝试对解码后的token应用Base64编码以实现修改时，则会导致最终生成的有效数字元数据不再具有完整性保障功能。通常情况下, 一种私钥结合特定加密算法会对Header字段及其附加声明(即Claims)进行处理从而生成唯一的数字签名,因此只有经过完整校验的数据元数据才可能与生成的有效数字元数据形成唯一对应关系。
这里有一个关键的实现细节。必须依赖私钥的应用程序（如服务器端应用）才能确认token包含声明信息的有效性。因此，在客户端中（如浏览器）不应存储或传输私钥信息。
OAuth2是什么？
与标准协议不同的是，OAuth2并非传统意义上的协议体系；该框架具体说明了系统内不同角色、用户、服务端应用（如API）以及客户端（如网站或移动应用程序）之间的交互认证流程。
与标准协议不同的是，OAuth2并非传统意义上的协议体系；该框架具体说明了系统内不同角色、用户、服务端应用（如API）以及客户端（如网站或移动应用程序）之间的交互认证流程。
The OAuth 2.0 authorization framework permits a third-party application to acquire restricted access to an HTTP service, either on behalf of a resource owner or independently, by orchestrating an approval interaction between the resource owner and the HTTP service. -RFC6749 https://tools.ietf.org/html/rfc6749
为了帮助大家更好地理解相关的基本概念，请您关注以下部分：我们已经将最新的一轮面试题目进行了整理，并将在第一时间发布相关信息，请您及时查看更新内容以便更好地准备考试。
Roles角色 应用程序或者用户都可以是下边的任何一种角色：
- 资源拥有者
- 资源服务器
- 客户端应用
- 认证服务器
Client Types 客户端类型 这里的客户端主要指那些依赖API进行操作的应用程序。它可以是以下类型的：
- 私有的
- 公开的
OAuth2框架同时明确定义了集中化的客户端描述用于表示应用程序的类型
- Web应用
- 用户代理
- 原声应用
认证授权机制（mechanism） 认证授权机制代表资源所有权者向目标应用程序授予一系列权限的方式与方法。它可以采用以下几种典型的形式：
- 授权码
- 隐式授权
- 资源拥有者密码证书
- 客户端证书
- Endpoints终端
OAuth2框架需要下边几种终端：
- 认证终端
- Token终端
- 重定向终端
使用HTTPS保护用户密码
在深入探讨OAuth2和JWT的实现细节之前
为了确保用户提供的私密信息能够得到安全传输，在任何情况下都是至关重要的。如果不采取适当的安全措施，则不允许任何人非法侵入个人无线网络，在用户登录时将窃取用户的登录信息。
一些重要的实施考虑 在做选择之前，参考一下下边提到的几点。
时间投入 OAuth2是一种安全框架，在不同场景下描述如何实现多个应用之间的授权问题。涉及大量学习资料的情况下深入学习该框架所需的时间投入较大。对于经验丰富的开发工程师而言，大概需要一个月时间才能深入掌握OAuth2标准规范。相比之下，JWT则是一个相对轻量级的概念。花大约一天时间就可以初步掌握JWT标准规范，并且从而可以较为容易地开始具体实施JWT的相关工作流程。
潜在的错误风险存在**OrthDoor 2（OAuth2）**与 JWT 不同的是一个严格的标准化协议，在实际应用中更容易出现问题。虽然存在许多现有的开源项目（开源项目），但不同开源项目的成熟度差异较大（开发周期长短），同样容易导致各种类型的实现缺陷（功能异常）。常见开源项目也往往隐藏着多种安全漏洞（逻辑漏洞）。当然，在实际应用中如果有一个高度成熟的开发团队持续进行 OAuth 2 的实现与维护，则可以一定程度地降低这些风险。
社交登录的核心优势 在实际应用中,通过利用用户已有的大型社交网站账户进行身份认证通常能够显著提升便利性。若希望实现用户的便捷接入,例如能够直接关联Facebook或Gmail等常见社交媒体账户,则借助现成的库将大大降低开发复杂性。
结论
在得出结论之前，我们先来列出JWT和OAuth2的主要应用场景。此外，一系列面试题及其答案已经整理完毕。微信公众号"Java技术栈"后台支持发送"面试"关键词进行在线阅读。
JWT使用场景
无状态的分布式API
JWT的主要优势在于以无状态且可扩展的方式处理应用中的用户会话。服务端能够通过内置声明信息较为轻松地获取用户的会话信息，并无需访问用户或其会话数据库。
在一个分布式基于服务的架构中提出此方案具有很高的适用性。然而，在系统设计中若采用基于黑名单的方法来实现长期有效的Token刷新机制时，则此方案的优势就不再突出。目前最新发布的面试题已全部整理完毕，请您访问Java面试库小程序进行在线练习，并关注后续更新信息。数学公式如下：P\{X=x\} = \sum_{y: y \leq x} P\{Y=y\}
优势
- 高效开发
- 无需登录
- 移端广泛采用JSON技术
- 无需社交登录支持
- 相对容易掌握的概念
限制
- Token存在字符长度上限
- Token不可撤销
- Token有效时长限定(exp)
- OAuth 2.0应用场景
在作者看来两种比较有必要使用OAuth2的场景：
外包认证服务器
在之前的讨论中提到过，在不介意外部第三方提供的验证服务的情况下进行API调用可能会带来一些复杂性。如果你愿意采用基于外部第三方提供的验证服务来进行API调用，则可以选择将这部分验证任务委托给专业的验证服务提供商完成。通常的做法是将企业的应用程序发送至可靠的第三方平台（例如Facebook），完成企业账户的注册，并设置必要的用户信息如电子邮箱、姓名等关键数据。
当访客访问网站的注册页面时,会发现一个指向第三方服务提供商入口的链接。访客点击链接后将被自动重定向至相应的认证服务提供商网站,在获取授权后能够访问所需信息,随后将返回原页面。