OAuth 2.0 授权方式讲解，规范实践和应用
基于实践说规范
网上看了一些OAuth 2.0的授权方法，尽管讲解的没有什么逻辑性错误，但是存在一个问题，那就是单纯的讲解协议规范却脱离了实际的应用，缺少干货，所以才有了这篇文章，内容基于实际业务进行讲解，力求基于实践说规范
OAuth 2.0
OAuth 引入了一个授权层，用来分离两种不同的角色：客户端和资源所有者。......资源所有者同意以后，资源服务器可以向客户端颁发令牌。客户端通过令牌，去请求数据。
OAuth 2.0 规定了四种获得令牌的流程。你可以选择最适合自己的那一种，向第三方应用颁发令牌。下面就是这四种授权方式。
授权码（authorization-code） 隐藏式（implicit） 密码式（password） 客户端凭证（client credentials）
分类解读
下面针对每一种进行详细的解读
授权码（authorization code）
该类型的授权最为常见也是最安全的授权方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌，微信、支付宝等大的开放平台使用的基本都是这种方式。
案例讲解：A网站要实现微信用户的授权登录功能，首先A需要在微信公众平台注册一个应用，一般需要填写应用图标、名称、回调链接等信息（有些平台需要上传对应的非对称加密的公钥用于访问的非对称加密），审核通过后平台为该应用分配对应的参数一般包括：appId，appsecret等信息。
A网站开发人员拿到对应的信息后，需要携带appid、appsecret等信息访问开放平台指定链接，例如：
| https://open.weixin.qq.com/connect/oauth2/authorize?appid=APPID&redirect_uri=REDIRECTURI&response_type=code&scope=SCOPE&state=STATE |
当用户点击授权后，平台会回调A网站在注册应用时提供的回调地址（有些平台需要申请授权时实时的提供），并携带code码（如有必要需要同时携带其他参数比如state参数），A网站拿到code码后通过平台提供的sdk获取openid、token、expired、refresh_oken、refesh_time等信息（code为参数调用开放平台接口获取参数）
用户拿到openid和token（令牌）就可以调用开放平台提供的服务了,到此，一个标准的授权码授权流程就结束了。需要知道的是token是有有效期的，适用方需要指定token刷新策略,通过refresh_oken调用刷新接口获取最新的token；
思考：为什么开放平台回调的时候是返回code，而不是直接返回token、openid等信息
- 直接返回token时涉及到跳转本身就是明文，可能被篡改的问题，需要协定复杂的签名协议来保证安全，这和 OAuth2 希望设计简洁验证模式的初衷违背；
- 一般情况下code是用后即失效并且时效较短，无法重复使用和超时使用，但是token的有效期较长，并且能重复使用，某个用户对应的openid对A网站来说是唯一的，不会发生变化；
- 要想获取token值需要提供appsecret作为参数（由第三方后端保存，不对外暴露），如果直接返回token，那么在页面授权的时候需要将appsecret显示的作为连接参数提供个开放平台，这显然不合理；
隐藏式（implicit）
有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749 就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）"隐藏式"（implicit）。
隐藏式授权的流程相对简单，但安全性不高，所以只能用于以下安全性要求不高的场景，其基本步骤如下：
第一步，A 网站提供一个链接，要求用户跳转到 B 网站，授权用户数据给 A 网站使用，如下：
https://b.com/oauth2/authorize?res_type=token& client_id=CLIENT_ID& . redirect_uri=CALLBACK_URL& scope=read
上面的url中res_type=token，标示返回的参数为token，也可以用其他的约定形式例如（authtype=implicit）
第二步，用户跳转到 B 网站，登录后同意给予 A 网站授权。这时，B 网站就会跳回redirect_uri参数指定的跳转网址，并且把令牌作为 URL 参数，传给 A 网站。
https://a.com/callback#token=ACCESS_TOKEN
注意，令牌的位置是 URL 锚点（fragment），而不是查询参数，这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。
关于token有效期的问题，一般采用隐藏式授权的的引用的有效期一般定为会话期间，随着浏览器关闭，令牌随之失效。一般不涉及到令牌的刷新问题（授权码授权需要定期的更新令牌）
密码式（password）
如果你高度信任某个应用，RFC 6749 也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）
tips：B验证通过后不进行页面跳转而是把令牌放到json数据里面，最晚http回应的形式，返回对应的数据，个人认为这种形式要暴露自己的用户名和密码，风险性太大，因此只适用于其他授权方式无法采用的情况，不建议使用，现实实践中一般情况下使用appkey+secret+solt+timstamp+body数据加密的形式代替这种授权方法
客户端凭证（client credentials）
适用于没有前端的应用，即：第三方应用直接将appid、secret等参数作为凭证，通过后台接口调用授权方接口，授权方验证通过后直接返回对应的token信息
https://b.com/oauth/token? grant_type=refresh_token& client_id=CLIENT_ID& client_secret=CLIENT_SECRET& refresh_token=REFRESH_TOKEN
OAuth2.0仅仅是个协议或者说是个规范，本身没有什么意义，它的意义在于为尝试为某种授权场景提供思路和规范，在设计自己的授权协议或者对接某开放平台的时候，能够思路清理的理解每一个步骤，并且做出正确的选择，显示时间中授权码的形式经常遇到，另外三种暂未遇到过，一般都是带有加密算法的变形应用（接口鉴权），小伙伴们要灵活掌握；在后面的文章中我会详细讲解接口鉴权的集中形式。
参考链接：http://www.ruanyifeng.com/blog/2019/04/oauth-grant-types.html
