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

(47) 2024-05-31 18:01:01

引言

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

  • 授权码(authorization-code)
  • 隐藏式(implicit)
  • 密码式(password):
  • 客户端凭证(client credentials)

一、授权码

介绍

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

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

流程:
微服务应用之OAuth2.0的四种授权方式 (https://mushiming.com/)  第1张

说明:

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)。

流程:
微服务应用之OAuth2.0的四种授权方式 (https://mushiming.com/)  第2张
说明:

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)

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

流程:
微服务应用之OAuth2.0的四种授权方式 (https://mushiming.com/)  第3张
说明:

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框架所要解决的问题。在这种模式中,用户直接向客户端注册,客户端以自己的名义要求"服务提供商"提供服务,其实不存在授权问题。

流程:
微服务应用之OAuth2.0的四种授权方式 (https://mushiming.com/)  第4张

附:参考资料

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

THE END

发表回复