转自：乐傻驴\链接：www.jianshu.com/p/1f2d6e5126cb本文将详细介绍两种通用的API安全保障方法：OAuth2和JSONWebToken(JWT)假设：你已经或正在实施应用程序接口；您正在考虑选择合适的方法来保证API的安全性；JWT和OAuth2比较？想比较JWT和OAuth2？首先要明白，这两者根本没有可比性，是完全不同的两个东西。JWT是一种身份验证协议JWT提供了一种颁发访问令牌（AccessToken）和验证颁发的签名访问令牌的方法。令牌（Token）本身包含了一系列的声明，应用程序可以根据这些声明来限制用户对资源的访问。OAuth2是一个授权框架另一方面，OAuth2是一个授权框架，它提供了一套详细的授权机制（指南）。用户或应用程序可以通过公共或私有设置授权第三方应用程序访问特定资源。既然JWT和OAuth2没有可比性，为什么要把这两个放在一起呢？在实践中，很多人会比较JWT和OAuth2。把这两个放在一起在标题中确实是误导。很多时候，在讨论OAuth2的实现时，都会使用JSONWebToken作为一种认证机制。这也是他们经常一起出现的原因。我们先搞清楚JWT和OAuth2是干什么的~JSONWebToken(JWT)JWT在标准中的定义如下：JWT中的声明被编码为使用JSONWeb签名(JWS)进行数字签名的JSON对象。-RFC7519https://tools.ietf.org/html/r...JWT是一种安全标准。基本思路是用户向认证服务器提供用户名和密码，服务器验证用户提交信息的合法性；iftheverificationissuccessful,aToken(token)willbegeneratedandreturned,andtheusercanusethistokentoaccessprotectedresourcesontheserver.一个token的例子:eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.TJVA95OrM7E2cBab30RMHrHDcEfxjoYZgeFONFh7HgQ一个token包含三部分：header.claims.signature了安全的在url中使用，所有部分都使用base64URL-safe进行编码处理。header部分简单声明了类型（JWT）和用于生成签名的算法。{"alg":"AES256","typ":"JWT"}Claimsclaimclaims部分是整个token的核心，代表要发送的用户详情。在某些情况下，我们很可能在一台服务器上实现认证，然后在另一台服务器上访问资源；或者，通过单独的接口生成令牌，令牌存储在应用程序客户端（如浏览器）中以供使用。简单声明示例：{"sub":"1234567890","name":"李四","admin":true}SignatureSignature签名的目的是保证以上两部分信息没有被篡改。如果尝试使用Bas64修改解码后的令牌，签名信息将失效。一般使用私钥通过特定的算法将Header和Claims混淆生成签名信息，因此只有原始token才能匹配到签名信息。这里有一个重要的实现细节。只有获得私钥的应用程序（如服务器端应用程序）才能充分验证令牌中包含的声明信息的合法性。因此，切勿将私钥信息放在客户端（如浏览器）上。什么是OAuth2？相反，OAuth2并不是一个标准的协议，而是一个安全的授权框架。详细描述了系统中如何实现不同角色、用户、服务前端应用（如API）、客户端（如网站或手机APP）之间的相互认证。OAuth2.0授权框架允许第三方应用程序获得对HTTP服务的有限访问权限，或者代表资源所有者通过编排资源所有者和HTTP之间的批准交互，或者允许第三方应用程序获得代表自己访问。-RFC6749https://tools.ietf.org/html/r...这里简单介绍一下涉及到的基本概念。Roles应用程序或用户可以是以下任意一种角色：资源拥有者资源服务器客户端应用认证服务器客户端类型客户端类型这里的客户端主要是指API的使用者。类型可以是：privatepublicClientProfile客户端描述OAuth2框架也规定了一个集中的客户端描述，用来表示应用的类型：WebapplicationuseragentoriginalsoundapplicationAuthorizationGrantsAuthenticationAuthorizationAuthorizationAuthorizationresourceownerA客户端应用程序的权限集可以采用以下形式：授权代码隐式授权资源所有者密码证书客户端证书端点终端OAuth2框架需要以下类型的终端：身份验证终端令牌终端从上面重定向终端应该看到，OAuth2定义一组相当复杂的规范。使用HTTPS保护用户密码在进一步讨论OAuth2和JWT的实现之前，有必要说一下，这两种方案都需要SSL安全保护，即对传输的数据进行加密编码。在任何安全系统中，用户提供的私人信息的安全传输都是必要的。否则任何人都可以通过侵入私人wifi窃取用户登录时的用户名和密码等信息。一些重要的实施注意事项在做出选择之前，请参考以下几点。时间投入OAuth2是一个描述各种场景下多个应用程序之间授权问题的安全框架。有大量的材料需要学习，并且需要花费大量时间才能完全理解。即使是一些经验丰富的开发工程师，要深入了解OAuth2也需要一个月左右的时间。这是一个很大的时间投资。相比之下，JWT是一个相对轻量级的概念。深入学习标准规范可能需要一天时间，你就可以轻松开始实施。错误风险OAuth2不像JWT那样是一个严格的标准协议，因此在实现过程中更容易出错。现有的库虽然很多，但是每个库的成熟度不在一个层次，也容易引入各种bug。在常用的库中也很容易找到一些安全漏洞。当然，如果有一个相当成熟和强大的开发团队进行OAuth2的持续实施和维护，这些风险是可以在一定程度上避免的。社交登录的好处在许多情况下，使用用户在大型社交网站上的现有帐户进行身份验证很方便。如果希望您的用户可以直接使用Facebook或Gmail等帐户，那么使用现有库会方便得多。结语在下结论之前，我们先罗列一下JWT和OAuth2的主要使用场景。JWT使用场景StatelessDistributedAPIJWT的主要优点是使用无状态、可扩展的方式来处理应用程序中的用户会话。服务器可以通过嵌入的声明信息轻松获取用户的会话信息，而无需访问用户或会话数据库。在分布式面向服务的框架中，这是非常有用的。但是，如果系统需要使用黑名单来实现一个长期有效的token刷新机制，这种无状态的优势就不明显了。优点快速开发不需要cookiesJSON在移动端的广泛应用不依赖于社交登录概念理解起来比较简单RestrictionToken有长度限制使用场景OAuth2：外包认证服务器如上所述，如果你不介意API的使用依赖于外部的第三方认证提供商，你可以将认证工作简单地交给认证服务提供商。去认证服务提供商（如facebook）注册你的也很常见应用程序，然后设置需要访问的用户信息，例如电子邮件地址、姓名等。当用户访问站点的注册页面时，他们会看到第三方提供商的入口。用户点击后，被重定向到相应的认证服务商网站。获得用户的授权后，他可以访问所需的信息，然后重定向回来。优点快速开发和实现代码维护量小减少大型企业解决方案如果你设计的API是要被不同的应用程序使用，并且每个应用程序的使用方式不同，那么使用OAuth2是一个不错的选择。考虑到工作量，可能需要单独的团队为各种应用制定全面灵活的安全策略。当然，这需要很多工作！OAuth2的作者也指出了这一点：需要明确的是，OAuth2.0由对网络安全有深刻理解的开发人员手中，很可能是一个安全的实现。然而，在大多数开发人员的手中——正如过去两年的经验一样——2.0可能会产生不安全的实现。hueniverse-OAuth2.0和地狱之路优点实现灵活可以和JWT同时使用可以针对不同的应用做进一步扩展http://jwt.io-JWT官网，也可以查看里面实现的库状态不同的语言。http://oauth.net/2/OAuth2官网，也可以查看不同语言实现的库的状态。OAuth2教程-关于OAuth2工作原理的有用概述Oauth2规范发布了EranHammer（推进OAuth标准的作者）关于OAuth2规范流程出了什么问题的观点。无论您有什么意见，最好由了解使安全标准成功的关键方面的人提出一些框架。理论和实现：使用Laravel和Angular在Laravel和Angular的理论和实践中真正提供JWT的信息指南。近期文章推荐：1.1,000+Java面试题及答案（2021最新版）2.别再满脑子if/else了，试试策略模式，真香！！3.操！Java中xx≠null的新语法是什么？4、SpringBoot2.5发布，深色模式太炸了！5.《Java开发手册（嵩山版）》最新发布，赶快下载吧！感觉不错，别忘了点赞+转发！
