OAuth2认证
OAuth 引入了一个授权层，用来分离两种不同的角色：客户端和资源所有者。资源所有者同意以后，资源服务器可以向客户端颁发令牌。客户端通过令牌，去请求数据。
其实这个 OAuth 的核心就是向第三方应用颁发令牌，而在 Oauth2 中定义了四种获得令牌的流程，也就是通俗的四种授权方式，但是我们经常使用的也就是那么一种。
- 授权码
- 隐藏式(简化)
- 密码式
- 客户端凭证
授权码模式
这是在 Oauth 里面的功能算是最完整的，而且流程最严密的授权模式。
授权码模式的步骤：
- 1.用户访问客户端，后者将前者导向认证服务器
- 2.用户选择是否给予客户端授权
- 3.假设用户给予授权，认证服务器将用户导向客户端事先指定的"重定向URI"（redirection URI），同时附上一个授权码
- 4.客户端收到授权码，附上早先的"重定向URI"，向认证服务器申请令牌。这一步是在客户端的后台的服务器上完成的，对用户不可见
- 5.认证服务器核对了授权码和重定向URI，确认无误后，向客户端发送访问令牌（access token）和更新令牌（refresh token）
其实授权码模式就相当于是第三方的应用去先申请一个授权码，然后再用该授权码获取令牌。
总结下来就是四个步骤 ：
1：请求授权码
2：返回授权码
3：请求令牌
4：返回令牌
我们给出一个例子，然后分析一下。
https://2.com/oauth/authorize? //授权地址 response_type=code& //参数1：response_type ：这里表示授权的类型，此处的值固定为"code" client_id=CLIENT_ID& //参数2：client_id ：表示客户端的ID redirect_uri=CALLBACK_URL& //参数3：redirect_uri ：表示重定向URL scope=read //参数4：scope： 表示申请的权限范围
上面的地址，就相当于第一步，携带所需要的参数请求 网站2，请求获取授权码。
https://1.com/callback?code=AUTHORIZATION_CODE //code 授权码
上面的地址就是第二步了，网站2给网站1返回授权码，
https://2.com/oauth/token? client_id=CLIENT_ID& 客户端ID client_secret=CLIENT_SECRET& 客户端密钥 grant_type=authorization_code& 使用的授权模式 authorization_code ：授权码模式 code=AUTHORIZATION_CODE& 授权码 redirect_uri=CALLBACK_URL 表示重定向URL
上面的地址就到第三步了，用授权码去索要令牌的请求就发送了。
请求发送完成后，2网站收到请求之后，这时候就向 重定向URL 发送以下的 JSON 数据，
{ "access_token":"ACCESS_TOKEN", //访问令牌 "token_type":"bearer",// 令牌类型 "expires_in":2592000, // 过期时间 "refresh_token":"REFRESH_TOKEN", // 更新令牌 "scope":"read", // 权限范围 只读 "uid":100101, // "info":{...} // }
这时候 访问令牌 我们就要有了，这完成所有的步骤后，我们就拿到了我们访问的令牌了，也就是我们完成了所需要的授权了。
隐藏式
其实隐藏式就是简化版的授权模式，他省略了获取 授权码 的过程，而是直接请求获取 令牌 的过程。
案例如下：
https://2.com/oauth/authorize? response_type=token& 授权的类型，此处的值固定为"token" client_id=CLIENT_ID& 客户端ID redirect_uri=CALLBACK_URL& 表示重定向URL scope=read 权限范围 只读
上面授权类型直接就是索要令牌，
第二步也很简单，就是直接给你返回你需要的令牌
https://1.com/callback#token=ACCESS_TOKEN
上面的 Token 就是我们需要的令牌了，
密码式
这种为什么称之为 密码式 ，是因为它在请求的时候，是用密码去换令牌，这就需要一个前提，你对这个网站有高度的信用度，如果你不信用他，他给你账号密码作用都不大，给了你也不会授权给它 Token 不是么。
案例步骤如下：
1.请求令牌
https://oauth.2.com/token? grant_type=password& 授权方式:指定为密码式 username=USERNAME& 用户名 password=PASSWORD& 密码 client_id=CLIENT_ID 客户端ID
2.返回令牌
https://1.com/callback#token=ACCESS_TOKEN
这个感觉和隐藏式差距不大，一个是直接要，一个是拿着参数要。
凭证式
这个凭证式的步骤也是比较少的，实际上阿粉感觉这种方式不知道算不算是授权的方式，因为这种模式是客户端以自己的名义向"授权服务提供者"进行认证，但是既然说是，那就暂且的认定他是，
1：请求令牌
https://oauth.2.com/token? grant_type=client_credentials& 授权方式:凭证式 client_id=CLIENT_ID& 客户端ID client_secret=CLIENT_SECRET 客户端密钥
2.返回令牌
https://1.com/callback#token=ACCESS_TOKEN
这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，也就是说可能出现多个用户共享同一个令牌。
为什么要比较 JWT 和Oauth2 ，因为很多不明所以的人总是会在挑选技术的时候，会把二者拿出来对比，其实上，他们两个没有可比性，因为 JWT 是用于发布接入令牌，并对发布的签名接入令牌进行验证的方法。
OAuth2是一种授权框架，授权第三方应用访问特定资源。
也就是说：
- OAuth2用在使用第三方账号登录的情况
- JWT是用在前后端分离, 需要简单的对后台API进行保护
所以你知道怎么选择了么？
文章参考
《阮一峰的网络日志》 《JWT官方文档》
