当我们在登录一些网站的时候，需要第三方的登录。比如，现在我们要登录简书https://www.jianshu.com/sign_in，我们使用微博登录，点击下方的一个微博的小按钮，就会出现这么一个地址https://api.weibo.com/oauth2/authorize?client_id=1881139527&redirect_uri=http%3A%2F%2Fwww.jianshu.com%2Fusers%2Fauth%2Fweibo%2Fcallback&response_type=code&state=%257B%257D。乍一看，这是什么玩意啊。我们来分解下：
https://api.weibo.com/oauth2/authorize? client_id=1881139527& redirect_uri=http%3A%2F%2Fwww.jianshu.com%2Fusers%2Fauth%2Fweibo%2Fcallback& response_type=code& state=%257B%257D
现在就要引出今天的主角了，OAuth2
那什么是OAuth2呢？
https://open.weibo.com/wiki/授权机制，这是微博的授权机制
http://www.ruanyifeng.com/blog/2014/05/oauth_2_0.html，这是阮一峰老师写的一篇对于OAuth2的介绍。
OAuth2.0是一个委托协议，它可用让那些控制资源的人允许某个应用代表这些人，而不是假冒和模仿这喜人，这个应用从资源的所有者哪里得到授权（Authentication）和Access Token，随后就可以使用这个Access Token来访问资源。（这里提到的假冒和模仿就是指在客户端复制一份用户名和密码，从而获取响应的权限）。是关于授权（Authentication）的，客户端应用可以请求Access Token，使用Tooken就可以访问API资源了。在上述的例子中，是微博给简书授权。
让客户端应用可以代表资源所有者（通常是用户）来访问被保护的资源，如下图：
资源所有者（Resource Owner），他拥有访问API资源的权限，并且他还可以委派权限（delegate）给其他应用来访问API。资源所有者通常是可以使用浏览器的人。
被保护的资源（Protected Resource）就是资源所有者拥有权限去访问的组件，它可以是很多种形式的，但是WebApi的形式还是最常见的。
客户端（Client）应用就是代表资源所有者访问被保护资源的一个软件，注意它既不是浏览器，也不是给你钱让你开发软件的人，在OAuth2里面，它是指被保护的API资源的消费者。
授权服务器（AS）是被受保护的资源所信任的，它可以发行具有特定目的的安全凭据给客户端应用，这个凭据就叫做OAuth的Access Token。
授权，如下图
授权种类：
1、Authentication Code
2、Implicit
3、Resource Owner Password Credentials，直接使用密码凭据（用户名和密码）作为授权来获得Access Token，只有当资源所有者和客户端之间高度新人的时候并且其它授权方式不可用的时候才可以使用这种授权方式。
4、Client Credentials，有时候，资源或者叫资源服务器，并不属于某个最终用户，也就是没有资源所有者对该资源负责，但是客户端应用肯定还是要访问这些资源，这时候就只能使用Client Credentials这种授权方式了。
其他重要角色和组件：
1、资源所有者Resource Owner
2、客户端Client
3、被保护资源 Protected Resource
4、授权服务器Authentication Server
5、Access Token，它是用来访问被保护资源的凭据，授权服务器只是方形Token，被保护资源验证Token，客户端队友Access Token应该是完全健忘的。
6、Scopes，被保护资源那里的一套权限，具有叠加性
7、Refresh Token，用来获得Access Token的凭据，客户端是用Refresh Token来请求信的Access Token
通过refresh token来取得新的access token的流程
重要端点：
1、授权端点（Authentication Endpoint）是用来和资源所有者交互的，资源所有者在这里进行登录（身份认证），然后通过该端点可以对客户端进行授权（Authentication Grant）。授权服务器首先要验证资源所有者的身份，但是验证的方式并不在OAuth2的协议范围内。
2、Token端点（Token Endpoint），客户端通过向Token端点展示它的授权（Authorization Grant）或Refresh Token来获取Access Token。除了Implicit之外所有的授权类型都需要使用该端点，因为Implicit和Access Token是直接发行的。
OpenId Connect（OIDC）
身份认证和授权。OAuth2不是身份认证（Authorization）协议，OpenId Connect可以进行身份认证（Authorization）。
一个比喻，授权，就好比生牛奶（多用途原料）；身份认证，就好比奶茶（一个最终产品），以牛奶为主原料。OAuth2，是生牛奶，众多web安全架构的一种多用途的基本成分。OIDC，好比奶茶，基于OAuth2的身份认证协议，添加了一些组件来提供身份认证的能力。
更高级的协议，扩展并代替了OAuth2。OpenID Connect是建立在OAuth2协议上的一个简单的身份标识层，所以OpenID Connect兼容OAuth2。使用OpenID Connect，客户端应用可以请求Identity Token，它会和Access Token一同返回给客户端应用。这个Identity Token就可以被用来登录客户端应用程序，而客户端应用还可以使用Access Token来访问API资源。UserInfo端点，（OAuth2定义了Authorization端点和Token端点）它允许客户端应用和获取用户的额外信息。定义了不同类型的应用如何从身份识别提供商（IDP）安全的获取到这些Token。
与OAuth 2.0之间的角色映射关系
1、身份供应商（Identity Provider，IdP）
2、依赖方（Relying Party，RP，可以理解Wie客户端）
3、OAuth2里面可以分为两部分
a、资源所有者/客户端应用
b、授权服务器/被保护资源
4、身份认证协议里也是两大不分
a、依赖方
b、身份提供商
5、映射OAuth2------OIDC
授权服务器/被保护资源-