Oauth2：
        是一种安全的授权框架，提供了一套详细的授权机制。用户或应用可以通过公开的或私有的设置，授权第三方应用访问特定资源。它详细描述了系统中不同角色、用户、服务前端应用（比如API），以及客户端（比如网站或移动App）之间怎么实现相互认证。

        Oauth2定义了一组想当复杂的规范。涉及到：Roles角色、Client Types客户端类型、Client Profile客户端描述、Authorization Grants认证授权、Endpoints终端等。

JWT：
        提供了一种用于发布接入令牌（Access Token),并对发布的签名接入令牌进行验证的方法。 令牌（Token）本身包含了一系列声明，应用程序可以根据这些声明限制用户对资源的访问。

        JWT是一种安全标准。基本思路就是用户提供用户名和密码给认证服务器，服务器验证用户提交信息信息的合法性；如果验证成功，会产生并返回一个Token（令牌），用户可以使用这个token访问服务器上受保护的资源。

        一个token包含三部分：header、claims、signature

        header:  头部分简单声明了类型(JWT)以及产生签名所使用的算法。

        { “alg” :”AES256”, “typ” :”JWT”}

        claims:  声明

        声明部分是整个token的核心，表示要发送的用户详细信息。有些情况下，我们很可能要在一个服务器上实现认证，然后访问另一台服务器上的资源；或者，通过单独的接口来生成token，token被保存在应用程序客户端（比如浏览器）使用。 以下一个简单的声明例子：

        { “sub”:”1234567890”, “name”:”John Doe”, “admin”:true}

        Signature：  签名

        签名的目的是为了保证上边两部分信息不被篡改。如果尝试使用Bas64对解码后的token进行修改，签名信息就会失效。一般使用一个私钥（private key）通过特定算法对Header和Claims进行混淆产生签名信息，所以只有原始的token才能于签名信息匹配。

        这里有一个重要的实现细节。只有获取了私钥的应用程序（比如服务器端应用）才能完全认证token包含声明信息的合法性。所以，永远不要把私钥信息放在客户端（比如浏览器）。

JWT和Oauth2的应用场景的区别：
jwt应用场景：  无状态的分布式API
        JWT的主要优势在于使用无状态、可扩展的方式处理应用中的用户会话。服务端可以通过内嵌的声明信息，很容易地获取用户的会话信息，而不需要去访问用户或会话的数据库。在一个分布式的面向服务的框架中，这一点非常有用。

但是，如果系统中需要使用黑名单实现长期有效的token刷新机制，这种无状态的优势就不明显了。

优势

        快速开发

        不需要cookie

        JSON在移动端的广泛应用

        不依赖于社交登录

        相对简单的概念理解

限制

        Token有长度限制

        Token不能撤销

        需要token有失效时间限制(exp)

Oauth2应用场景：
1）外包认证服务器

        上边已经讨论过，如果不介意API的使用依赖于外部的第三方认证提供者，你可以简单地把认证工作留给认证服务商去做。

        也就是常见的，去认证服务商（比如facebook）那里注册你的应用，然后设置需要访问的用户信息，比如电子邮箱、姓名等。当用户访问站点的注册页面时，会看到连接到第三方提供商的入口。用户点击以后被重定向到对应的认证服务商网站，获得用户的授权后就可以访问到需要的信息，然后重定向回来。

优势

        快速开发

        实施代码量小

        维护工作减少

2）大型企业解决方案

        如果设计的API要被不同的App使用，并且每个App使用的方式也不一样，使用OAuth2是个不错的选择。

        考虑到工作量，可能需要单独的团队，针对各种应用开发完善、灵活的安全策略。当然需要的工作量也比较大！这一点，OAuth2的作者也指出过：

https://www.jianshu.com/p/1870f456b334

A）客户端向资源所有者请求授权。授权请求可以直接对资源所有者(如图所示)进行，或者通过授权服务器作为中介进行间接访问（首选方案）。
（B）资源所有者允许授权，并返回凭证（如code）。
（C）客户端通过授权服务器进行身份验证，并提供授权凭证（如code），请求访问令牌（access token）。
（D）授权服务器对客户端进行身份验证，并验证授权凭证，如果有效，则发出访问令牌。
（E）客户端向资源服务器请求受保护的资源，并通过提供访问令牌来进行身份验证。
（F）资源服务器验证访问令牌，如果正确则返回受保护资源。
简单说就是：客户应用向授权服务器请求Access Token —> 授权服务器向用户征询意见，是否将权限授予客户应用 —> 用户同意 —> 授权服务器生成颁发Access Token给客户应用 —> 客户应用拿着Access Token去请求资源服务器 —> 资源服务器验证客户应用的Access Token —> 验证通过，返回数据

三、OAuth2中的角色和术语
在OAuth2中主要有四个角色，主要如下：

Resource Owner(资源所有者)：用户，即资源的拥有人，想要分享某些资 源给第三方应用
Resource Server(资源服务器)：放受保护资源，要访问这些资源，需要获得访问令牌
Authorization server(授权（认证）服务器)：授权服务器用于发放访问令牌给客户端
Client(客户端（第三方应用）)：客户端代表请求资源服务器资源的第三方程序
OAuth2中的其他术语：

Client Credentials(客户凭证)：客户的clientId 和密码用于认证客户
Access Token(访问令牌)：授权服务器在接收到客户请求后，颁发的访问令牌
Scopes(作用域)：客户请求访问令牌时,由资源拥有者额外指定的细分权限(permission)
User Agent(用户代理)：用户代理。一般就是指浏览器
OAuth2中的令牌类型：

Authorization Code Token(授权码)：仅用于授权码授权类型,用于交换获取访问令牌和刷新令牌
Refresh Token(刷新令牌)：用于去授权服务器获取一个新的访问令牌
Access Token(访问令牌)：用于代表一个用户或服务直接去访问受保护的资源
Proof of Possession(PoP) Token(持有证明(pop)令牌)：可以校验client是否对Token 有明确的拥有权
通过上面的介绍我们大概总结如下：

OAuth的本质在于如何获取token，如何使用token
OAuth是一种在系统之间的代理授权(delegation authorization)协议
OAuth提供一个宽泛的协议框架，具体安全场景需要定制
OAuth使用代理协议的方式解决密码共享反模式问题
四、OAuth2的四种授权方式
从运行流程不难看出，要获取access token必须先得到用户授权（authorzation grant），那么如果获取这么用户授权呢？OAuth 2.0定义了四种类型的授权类型

授权码模式（authorization code）
简化模式（implicit）
密码模式（resource owner password credentials）
客户端模式（client credentials）

https://blog.csdn.net/Anumbrella/article/details/99710044

https://studygolang.com/articles/17363