OAuth2：Authorization Flows

Ref：http://www.dannysite.com/blog/176/

OAuth2.0协议定义了用于得到受权的四种主要受权类型。

1. Client Credentials

一种基于APP的密钥直接进行受权，所以APP的权限很是大。它适合像数据库或存储服务器这种对API的访问需求。

示例：

当初作Wish API的时候，Wish官方的受权直接给一个Token，访问的时候直接传token附带在https请求中就能够了。属于Wish API 1.0 时代的产物。

2. Authorization code

标准的Server受权模式，很是适合Server端的Web应用。一旦资源的拥有者受权访问他们的数据以后，他们将会被重定向到Web应用并在URL的查询参数中附带一个受权码（code）。在客户端里，该code用于请求访问令牌（access_token）。而且该令牌交换的过程是两个服务端以前完成的，防止其余人甚至是资源拥有者本人获得该令牌。另外，在该受权模式下能够经过refresh_token来刷新令牌以延长访问受权时间。

示例：

Wish API 2.0后，就是使用此方式，填完用户信息，要去AuthServer得到一个Code，而后根据Code再去拿一个Access Token。

• 1.https://merchant.wish.com/oauth/authorize?client_id={client_id}
• 2.https://localhost/authcode?code={authorization_code}
• 3.根据{authorization_code}，POST

POST https://merchant.wish.com/api/v2/oauth/access_token

Parameters
client_id   Your app's client ID
client_secret   Your app's client secret
code    The authorization code you received
grant_type  The string 'authorization_code'
redirect_uri    Your app's redirect uri that you specified when you created the app

• 4.访问的时候，Authorization: Bearer {access_token}

POST https://merchant.wish.com/api/v2/auth_test

Parameters
access_token    Your access token

参考官方文档：https://merchant.wish.com/documentation/oauth。

3. Implicit Grant

该模式是全部受权模式中最简单的一种，并为运行于浏览器中的脚本应用作了优化。当用户访问该应用时，服务端会当即生成一个新的访问令牌（access_token）并经过URL的#hash段传回客户端。这时，客户端就能够利用JavaScript等将其取出而后请求API接口。该模式不须要受权码（code），固然也不会提供refresh token以得到长期访问的入口。

4. Resource Owner Password Credentials

这种模式要求用户提供用户名和密码来交换访问令牌（access_token）。该模式仅用于很是值得信任的用户，例如API提供者本人所写的移动应用。虽然用户也要求提供密码，但并不须要存储在设备上。由于初始验证以后，只需将OAuth的令牌记录下来便可。若是用户但愿取消受权，由于其真实密码并无被记录，所以无需修改密码就能够当即取消受权。token自己也只是获得有限的受权，所以相比最传统的username/password受权，该模式依然更为安全。