微服务应用之OAuth2.0的四种授权方式

引言

OAuth 2.0 是一种授权机制，主要用来颁发令牌（token）。
OAuth 2.0 的标准是 RFC 6749 文件，这个文件写出（由于互联网有多种场景，）本标准定义了获得令牌的四种授权方式（authorization grant ）
即以下四种授权方式：

• 授权码（authorization-code）
• 隐藏式（implicit）
• 密码式（password）：
• 客户端凭证（client credentials）

一、授权码

介绍：

授权码（authorization code）方式，指的是第三方应用先申请一个授权码，然后再用该码获取令牌。

这种方式是最常用的流程，安全性也最高，它适用于那些有后端的 Web应用。授权码通过前端传送，令牌则是储存在后端，而且所有与资源服务器的通信都在后端完成。这样的前后端分离，可以避免令牌泄漏。

流程：

说明：

A [步骤1，2]：用户访问客户端，需要使用服务提供商（微信）的数据，触发客户端相关事件后，客户端拉起或重定向到服务提供商的页面或APP。
B [步骤3]：用户选择是否给予第三方客户端授权访问服务提供商（微信）数据的权限；
C [步骤4]：用户同意授权，授权认证服务器将授权凭证code码返回给客户端，并且会拉起应用或重定（redirect_uri）向到第三方网站；
D [步骤5，6]：客户端收到授权码后，将授权码code和ClientId或重定向URI发送给自己的服务器，客户端服务器再想认证服务器请求访问令牌access_token;
E[步骤7，8]：认证服务器核对了授权码和ClientId或重定向URI，确认无误后，向客户端服务器发送访问令牌（access_token）和更新令牌（refresh_token），然后客户端服务器再发送给客户端；
F[步骤9，10]：客户端持有access_token和需要请求的参数向客户端服务器发起资源请求，然后客户端服务器再向服务提供商的资源服务器请求资源（web API）；
G [步骤11，12，13]：服务提供商的资源服务器返回数据给客户端服务器，然后再回传给客户端使用；

A步骤中客户端申请认证的URI，包含以下参数：

https://server.example.com/oauth/auth?response_type=code&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read         

• response_type：必选项，表示授权类型，此处的值固定为"code"，表示使用授权码模式；
• client_id：必选项，表示客户端的ID，第三方应用注册的id，身份认证；
• redirect_uri：可选项，表示重定向URI，接受或拒绝请求后的跳转网址；
• scope：可选项，表示申请的权限范围；
• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值

C步骤中，服务器回应客户端的URI，包含以下参数：

https://server.example.com/callback?code=AUTHORIZATION_CODE&state=xyz

• code：表示授权码，该码的有效期应该很短，通常设为10分钟，客户端只能使用该码一次，否则会被授权服务器拒绝。该码与客户端ID和重定向URI，是一一对应关系。
• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数

D步骤中，客户端向认证服务器申请令牌的HTTP请求，包含以下参数：

https://server.example.com/oauth/token?client_id=CLIENT_ID&client_secret=CLIENT_SECRET&grant_type=authorization_code&code=AUTHORIZATION_CODE&redirect_uri=CALLBACK_URL

• client_id：客户端id，第三方应用在服务提供者平台注册的；
• client_secret：授权服务器的秘钥，第三方应用在服务提供者平台注册的；
• grant_type：值是AUTHORIZATION_CODE，表示采用的授权方式是授权码；
• code：表示上一步获得的授权码;
• redirect_uri：redirect_uri参数是令牌颁发后的回调网址,且必须与A步骤中的该参数值保持一致;

E步骤中，认证服务器发送的HTTP回复，包含以下参数：

{    
  "access_token":"ACCESS_TOKEN",
  "token_type":"bearer",
  "expires_in":2592000,
  "refresh_token":"REFRESH_TOKEN",
  "scope":"read",
  "uid":100101,
  "info":{...}
}

access_token字段就是访问令牌

二、隐藏式

介绍：

有些 Web 应用是纯前端应用，没有后端。这时就不能用上面的方式了，必须将令牌储存在前端。RFC 6749就规定了第二种方式，允许直接向前端颁发令牌。这种方式没有授权码这个中间步骤，所以称为（授权码）“隐藏式”（implicit）。

流程：

说明：

A [步骤1，2]：用户访问客户端，需要使用服务提供商（微信）的数据，触发客户端相关事件后，客户端拉起或重定向到服务提供商的页面或APP。
B [步骤3]：用户选择是否给予第三方客户端授权访问服务提供商（微信）数据的权限；
C [步骤4]：用户同意授权，授权认证服务器将访问令牌access_token返回给客户端，并且会拉起应用或重定（redirect_uri）向到第三方网站；
D[步骤5]：第三方客户端向资源服务器发出请求资源的请求；
E[步骤6，7]：服务提供商的资源服务器返回数据给客户端服务器，然后再回传给客户端使用

A步骤中，客户端发出的HTTP请求，包含以下参数：

https://server.example.com/oauth/authorize?response_type=token&client_id=CLIENT_ID&redirect_uri=CALLBACK_URL&scope=read

• response_type：表示授权类型，此处的值固定为"token"，表示要求直接返回令牌，必选项；
• client_id：表示客户端的ID，第三方应用注册的id，用于身份认证，必选项；
• redirect_uri：表示重定向URI，接受或拒绝请求后的跳转网址，可选项；
• scope：表示申请的权限范围，可选项；
• state：表示客户端的当前状态，可以指定任意值，认证服务器会原封不动地返回这个值

C步骤中，认证服务器回应客户端的URI，包含以下参数：

https://server.example.com/cb#access_token=ACCESS_TOKEN&state=xyz&token_type=example&expires_in=3600
或
https://a.com/callback#token=ACCESS_TOKEN

• access_token：表示访问令牌，必选项。
• token_type：表示令牌类型，该值大小写不敏感，必选项。
• expires_in：表示过期时间，单位为秒。如果省略该参数，必须其他方式设置过期时间。
• scope：表示权限范围，如果与客户端申请的范围一致，此项可省略。
• state：如果客户端的请求中包含这个参数，认证服务器的回应也必须一模一样包含这个参数。

注意，令牌的位置是 URL 锚点（fragment），而不是查询字符串（querystring），这是因为 OAuth 2.0 允许跳转网址是 HTTP 协议，因此存在"中间人攻击"的风险，而浏览器跳转时，锚点不会发到服务器，就减少了泄漏令牌的风险。

三、密码式

介绍：

如果你高度信任某个应用，RFC 6749也允许用户把用户名和密码，直接告诉该应用。该应用就使用你的密码，申请令牌，这种方式称为"密码式"（password）

使用用户名/密码作为授权方式从授权服务器上获取令牌，一般不支持刷新令牌。这种方式风险很大，用户向客户端提供自己的用户名和密码。客户端使用这些信息，向"服务商提供商"索要授权。在这种模式中，用户必须把自己的密码给客户端，但是客户端不得储存密码。这通常用在用户对客户端高度信任的情况下，而认证服务器只有在其他授权模式无法执行的情况下，才能考虑使用这种模式。

流程：

说明：

A[步骤1，2]：用户向第三方客户端提供，其在服务提供商那里注册的账户名和密码；
B[步骤3]：客户端将用户名和密码发给认证服务器，向后者请求令牌access_token；
C[步骤4]：授权认证服务器确认身份无误后，向客户端提供访问令牌access_token；

B步骤中，客户端发出的HTTP请求，包含以下参数：

https://oauth.example.com/token?grant_type=password&username=USERNAME&password=PASSWORD&client_id=CLIENT_ID

• grant_type： 标识授权方式，这里的password表示"密码式，必选项；
• username： 表示用户名，必选项；
• password： 表示用户的密码，必选项；
• scope： 表示权限范围，可选项；

四、凭证式

介绍：

指客户端以自己的名义，而不是以用户的名义，向"服务提供商"进行认证。严格地说，客户端模式并不属于OAuth框架所要解决的问题。在这种模式中，用户直接向客户端注册，客户端以自己的名义要求"服务提供商"提供服务，其实不存在授权问题。

流程：

附：参考资料

1、OAuth2.0原理浅析
2、OAuth 2.0 的四种方式
3、理解OAuth 2.0