什么是Oauth2.0,Oauth2.0的四种授权模式

Oauth2.0本身:

Oauth2.0是一种授权协议,当然也归属为安全协议的范畴,在实际执行的时候就是保护互联网中不断增长的大量WEB API的安全访问。OAuth2.0共包含四种角色,分别是资源所有者、第三方应用(也称为客户端client)、授权服务器和资源服务器。如下图所示,某公司A开发了一个微信小程序(第三方应用)可以帮助我(资源所有者)美化微信服务器(资源服务器)上面的头像,我在用这个微信小程序开发的美化头像功能的时候,首先要给微信小程序授权(授权服务器),这个微信小程序才能访问我的头像,实际上访问的时候微信小程序就是通过WEB API来调用的。授权的过程中我是不可能把我的账号密码给它的,这样的前提下就会有另外方式的授权,也就是上面介绍的现在国际通用的标准OAuth2.0。

在这里插入图片描述

OAuth2.0协议流程描述了四种角色之间的交互过程,如下图所示。

在这里插入图片描述

上面的序列图一共分为以下6个步骤:

(1)第三方应用请求资源所有者授权。

(2)资源所有者同意给第三方应用授权。

(3)第三方应用使用步骤2中获得的授权,向授权服务器申请令牌。

(4)授权服务器对第三方应用进行认证并确认无误后,同意发放令牌。

(5)第三方应用使用步骤4中发放的令牌向资源服务器申请获取资源。

(6)资源服务器确认令牌无误后,向第三方应用开放资源访问。

简单说,OAuth 就是一种授权机制。数据的所有者告诉系统,同意授权第三方应用进入系统,获取这些数据。系统从而产生一个短期的进入令牌(token),用来代替密码,供第三方应用使用。

令牌与密码

令牌(token)与密码(password)的作用是一样的,都可以进入系统,但是有三点差异。

(1)令牌是短期的,到期会自动失效,用户自己无法修改。密码一般长期有效,用户不修改,就不会发生变化。

(2)令牌可以被数据所有者撤销,会立即失效。以上例而言,屋主可以随时取消快递员的令牌。密码一般不允许被他人撤销。

(3)令牌有权限范围(scope),比如只能进小区的二号门。对于网络服务来说,只读令牌就比读写令牌更安全。密码一般是完整权限。

上面这些设计,保证了令牌既可以让第三方应用获得权限,同时又随时可控,不会危及系统安全。这就是 OAuth 2.0 的优点。

注意,只要知道了令牌,就能进入系统。系统一般不会再次确认身份,所以令牌必须保密,泄漏令牌与泄漏密码的后果是一样的。 这也是为什么令牌的有效期,一般都设置得很短的原因。

OAuth 2.0 对于如何颁发令牌的细节,规定得非常详细。具体来说,一共分成四种授权类型(authorization grant),即四种颁发令牌的方式,适用于不同的互联网场景。

1. 隐式授权模式(Implicit Grant)
在这里插入图片描述

  • 第一步:用户访问页面时,重定向到认证服务器。
  • 第二步:认证服务器给用户一个认证页面,等待用户授权。
  • 第三步:用户授权,认证服务器想应用页面返回Token
  • 第四步:验证Token,访问真正的资源页面

在这里插入图片描述

2. 授权码授权模式(Authorization code Grant)
在这里插入图片描述

  • 第一步:用户访问页面
  • 第二步:访问的页面将请求重定向到认证服务器
  • 第三步:认证服务器向用户展示授权页面,等待用户授权
  • 第四步:用户授权,认证服务器生成一个code和带上client_id发送给应用服务器
    然后,应用服务器拿到code,并用client_id去后台查询对应的client_secret
  • 第五步:将code、client_id、client_secret传给认证服务器换取access_token和
    refresh_token
  • 第六步:将access_token和refresh_token传给应用服务器
  • 第七步:验证token,访问真正的资源页面

在这里插入图片描述

3. 密码模式(Resource Owner Password Credentials Grant)

  • 第一步:用户访问用页面时,输入第三方认证所需要的信息(QQ/微信账号密码)
  • 第二步:应用页面那种这个信息去认证服务器授权
  • 第三步:认证服务器授权通过,拿到token,访问真正的资源页面

优点:不需要多次请求转发,额外开销,同时可以获取更多的用户信息。(都拿到账号密码了)

缺点:局限性,认证服务器和应用方必须有超高的信赖。(比如亲兄弟?)

应用场景:自家公司搭建的认证服务器

4. 客户端凭证模式(Client Credentials Grant)

  • 第一步:用户访问应用客户端
  • 第二步:通过客户端定义的验证方法,拿到token,无需授权
  • 第三步:访问资源服务器A
  • 第四步:拿到一次token就可以畅通无阻的访问其他的资源页面。

这是一种最简单的模式,只要client请求,我们就将AccessToken发送给它。这种模式是最方便但最不安全的模式。因此这就要求我们对client完全的信任,而client本身也是安全的。

因此这种模式一般用来提供给我们完全信任的服务器端服务。在这个过程中不需要用户的参与。