OAuth 2.0

概念

OAuth 2.0是一个关于开放授权的网络协议。
该协议允许用户授权第三方应用访问该用户在某一站点（如QQ、微信、微博等等）上存储的的资源（如：个人资料、照片，视频，联系人列表），而无需将站点的用户名和密码提供给第三方应用

OAuth在第三方应用与服务提供商之间设置了一个授权层。第三方应用不能直接登录服务提供商，只能登录授权层，以此将用户与客户端区分开来。第三方应用登录授权层所用的令牌，与用户的密码不同。用户可以在登录授权的时候，指定授权层令牌的权限范围和有效期。 第三方应用登录授权层以后，服务提供商根据令牌的权限范围和有效期，向第三方应用开放用户资源。
核心就是服务提供商向第三方应用颁发令牌，第三方应用通过令牌访问用户资源

前提

第三方应用向服务提供商申请分配应用client_id及client_secret，配置授权后重定向uri

协议流程

image.png

（A）用户打开客户端以后，客户端要求用户给予授权。
（B）用户同意给予客户端授权。
（C）客户端使用上一步获得的授权，向认证服务器申请令牌。
（D）认证服务器对客户端进行认证以后，确认无误，同意发放令牌。
（E）客户端使用令牌，向资源服务器申请获取资源。
（F）资源服务器确认令牌无误，同意向客户端开放资源。
B用户如何授权是最关键的步骤，以下介绍标准中的四种授权方式

四种授权方式

OAuth 2.0 的四种方式
授权码（authorization-code）
隐藏式（implicit）
密码式（password）
客户端凭证（client credentials）

针对特定用户：授权码、隐藏式、密码式授权方式服务提供商随意提供一种即可，但最常用的是授权码和隐藏式。如QQ提供授权码和隐藏式两种方式供第三方应用自行选择
针对应用：客户端凭证

授权码

授权码模式是四种模式中最繁琐也是最安全的一种模式。

image.png

1、第三方应用将用户重定向至服务提供商的授权界面（一般是authorize接口，参数中限制访问scope），用户采用密码或者扫码等方式成功登录后，服务提供商将URL重定向至第三方应用配置好的回调URL，并将授权码code拼接在URL参数中返回
2、第三方应用将上一步获取到的code，以及client_id、client_secret、redirect_uri等参数拼装请求服务提供商的token接口，获取该用户的访问令牌token
3、第三方应用利用上一步获取到的token获取用户信息等接口，具体参照各个服务提供商的API文档

隐藏式

适用于无服务端的公开的浏览器单页应用，与授权码模式区别是在第一步的authorize接口通过client_id直接向前端颁发令牌，而授权码模式还需要client_secret向服务提供商获取令牌。
这种方式把令牌直接传给前端，是很不安全的。因此，只能用于一些安全要求不高的场景，并且令牌的有效期必须非常短，通常就是会话期间（session）有效，浏览器关掉，令牌就失效了。

image.png

密码式

用户高度信任第三方应用，直接提供用户名/密码给该应用，该应用使用用户名/密码作为授权方式从授权服务器上获取令牌。
这种方式需要用户给出自己的用户名/密码，显然风险很大，因此只适用于其他授权方式都无法采用的情况，而且必须是用户高度信任的应用。

image.png

客户端凭证

这种方式给出的令牌，是针对第三方应用的，而不是针对用户的，无需用户授权。即可直接通过client_id、client_secret直接获取应用令牌。例如调用微信公众号接口之前都必须先获取应用的ACCESS_TOKEN才可发起访问

image.png