Oauth2协议简介
Oauth2.0
Oauth2是一种委托协议（虽然他被叫做授权协议，但本质上是一个委托协议），你可以通过Oauth2协议授权给某个应用程序，让该应用程序代替你去访问你的某些资源。资源拥有者（你）授权给某个应用，该应用会获得一个token（类似委托书，代表着这个这个应用获取了你的授权，可以代表你），这个应用带着这个token代表你去资源服务器获取你的某些资源。
举个生活中的例子：如果你要买车，车子付钱之后要上牌，但是你有没有时间，4s店提供代办服务。但是4s店代办车牌需要你的完税证明及委托书等证明才能去车管所代办。你需要以委托书的形式授权给4s店，委托4s帮你代办。Oauth2就是办理委托和授权的协议。
最最重要的：Oauth2不是认证协议，没有认证的功能。
最最最重要的是：token中只有你授权的权限。你本身可能有很多权限，你可以只选择一部分权限授权给应用，token代表了你授权的权限。
最最最最重要的是：这种授权时临时的，有时间期限。第三方应用不能永远代表你去访问这些资源。因此，token是临时的，临时授权。
到底什么是Oauth2?
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.
Oauth2是个授权框架，它可以使某个第三方引用获取到对某个HTTP服务有限的访问权限。这种权限的获得可以通过编排一个资源拥有者和HTTP服务之间的授权交互流程获得，也可以通过三方应用自己的行为获取权限。
Oauth2协议中涉及到的几种角色：
Resource Owner: 资源拥有者，指用户。
Reosurce Server: 资源服务器，存放Protected Resource.用户的资源在资源服务器上存储保存，使用时需要到资源服务器获取.
Client: 第三方应用（可以认为是某个微服务）。这个应用（服务）想要代表用户去获取资源服务器上用户的一些资源。
User-Agent: 简单认为就是浏览器。
Oauth2的目的就是 让Client能够访问用户在资源服务器上的资源（取得用户的某种权限），并且在这期间不出现安全隐患。这种权限的取得：
1. 不会让Client知道用户的账号密码
2. 不会有越权访问，比如资源服务器上有很多资源，但只授权client访问部分资源
3. 临时授权，授权存在一定期限，期限过去之后就不能访问了。再访问需要再次申请用户的允许。
Oauth2协议的流程：
Client（某个微服务）想要访问Resource Server上的资源，流程如下:
1. Client要获取用户的授权，因此它将Resource Owner 引导至Authorization Server（通过浏览器redirect的方式）
2. 授权服务器向用户展示出权限列表，用户勾选授予Client的权限，并点击授权按钮，将授权结果告知给授权服务器
3. 授权服务器获取到授权信息后，发一个授权码（Authorization Grant,也称为grant_code,授权码代表着用户的授权）并将这个授权码给到Client
4. Client拿到授权码之后，拿着授权码向资源服务器请求获取一个access token(访问码，访问凭证)
5. Client拿着访问码去资源服务器访问它想要获取的资源。
这是Oauth2协议的一般流程。实际上Oauth2有好几种授权流程，后续再说。
记住：Oauth是一个委托协议，没有认证功能。它只是让Client安全的取得用户授权的一种方法。在整个流程中，只有资源服务器、授权服务器和用户知道哪些权限。Client只能呆呆的拿着访问凭证（access_token）去访问资源，它不知道access token代表着什么，有什么意义，只知道带着这个凭证就可以访问资源。Oauth2将资源是否应该被Client访问交给用户做决策，传统的要么是服务器偷偷摸摸替用户做决策（不民主，侵犯用户权利），要么让询问用户提供账号密码（密码暴露不安全，会越权，且用户无法回收）。
比如。你是老板，让员工去办事，员工说我办不成啊，人家不给我面子。你说我给你各钢笔，你带着这只钢笔过去 他就给你办。但是这钢笔为什么管用，钢笔有啥秘密，员工理解不了。
理解了这些，大概就能理解Oauth2协议解决的问题是什么了。
Oauth2的优缺点
优点：
Oauth2在设计之初就考虑到 Client的数量要比资源服务器或授权服务器高出几个数量级。考虑到一个授权服务器需要保护多个资源服务器，并且访问资源服务器的client是多种多样五花八门（这些客户端实现不一，对服务器来说能不能信任，能信任多大程度也不知道），因此将实现的复杂性交给授权服务器（因为授权服务器少，保障一个服务器的安全总比保障五花八门的client的安全容易的多）。因此Client是整个Oauth2协议中最简单的，最傻最呆的。Client的开发者不需要处理签名、解析复杂安全策略，甚至都不要关心用户账号密码的安全（它也见不到啊）。客户端只需要关心它自己的Client凭证（client id和client secret）及它获取到的access token的安全即可。客户端收到攻击，也不会暴露用户的账号密码，最多只会影响到这个客户端自己，也不会影响全局。但授权服务器需要保证所有用户账号密码的安全，需要保证所有Client凭证的安全。
缺点：
Oauth2为了保证灵活性和适用性，有很多地方都没有做出明确的定义，而是让开发者自己去实现。甚至一些定义的选项都被错误的使用，导致实现的Oauth2协议都不安全（后续会提到）。最恶心的是，有些Oauth2协议明明是按照协议规范实现的，在实际系统中还是不安全（使用时变得不安全了，client没考虑到）。
Oauth2协议的核心是 client如何获取一个access token 以及如何使用这个access token，是个委托协议用于实现跨系统授权。
Oauth2协议实现强依赖HTTPS，因为token会携带用户信息或者授权，因此要保障token的安全性。
补充说明：
1. 再次强调，Oauth2不是认证协议，没有认证功能。client自始至终都不知道用户是谁，给了什么权限。client对用户信息一无所知，不可能知道用户是谁，认证也就无从谈起。
2. Oauth协议没有规定授权的处理过程及处理机制，授权服务器自己实现。
3. Oauth2协议没有规定token的格式，没有说token必须使用jwt.
4. Oauth2协议没有规定加密方法，据说是故意的。为了让大家使用JSON Object Signing and Encryption (JOSE)规范家族。
