OAuth API访问授权的开放标准

OAuth

OAUTH协议为用户资源的授权提供了一个安全的、开放而又简易的标准。与以往的授权方式不同之处是OAUTH的授权不会使第三方触及到用户的帐号信息(如用户名与密码),即第三方无需使用用户的用户名与密码就可以申请获得该用户资源的授权,因此OAUTH是安全的。oAuth是Open Authorization的简写。

协议特点

  1. 简单:不管是OAUTH服务提供者还是应用开发者,都很易于理解与使用;
  2. 安全:没有涉及到用户密钥等信息,更安全更灵活;
  3. 开放:任何服务提供商都可以实现OAUTH,任何软件开发商都可以使用OAUTH;

授权流程

OAUTH认证授权就三个步骤,三句话可以概括:

  1. 获取未授权的Request Token;
  2. 获取用户授权的Request Token;
  3. 用授权的Request Token换取Access Token;

OAuth2.0

OAuth 2.0定义了四种授权方式,也就是四种获得令牌的方式。

  • 授权码模式
  • 简化模式
  • 密码模式
  • 客户端模式

授权码模式(Authorization Code Grant)

是功能最完整、流程最严密的授权模式。它的特点就是通过客户端的后台服务器,与”服务提供商”的认证服务器进行交付,先获得服务提供商的授权码,然后再用授权码去获取令牌。

目前在网站和APP登录上普遍采用的就是授权码模式。

OAuth API访问授权的开放标准

授权码模式的工作流程如下:

  1. 登录页面选择qq登录,向豆瓣的服务器发起了 http://www.douban.com/leadToAuthorize 的请求,豆瓣服务器会响应一个重定向地址。
  2. 浏览器访问重定向地址 http://www.qq.com/authorize?callback=www.douban.com/callback ,这次访问带了一个参数是callback。
  3. qq的服务器接受到了授权申请,响应是跳转到qq的登录页面。用户输入账号密码点击授权并登录按钮。
  4. qq服务器校验用户名密码,若校验成功,会响应浏览器一个重定向地址,并附上一个code(授权码)。
  5. 浏览器接到重定向,向豆瓣发起 http://www.douban.com/callback?code=xxx 请求,并带code参数。
  6. 豆瓣服务器收到请求后,又发起了两次请求。第一次是用拿到的code去换token,第二次就是用拿到的token换取用户信息。

简化模式(Implicit Grant)

是不通过第三方应用程序的服务器,直接在浏览器中向认证服务器申请令牌,跳过了”授权码”这个步骤,因此得名。所有步骤均在浏览器中完成,令牌对访问者是可见的。

简化模式是把令牌直接传给前端,是很不安全的,存在中间人攻击的风险。因此,只能用于一些安全要求不高的场景,并且令牌的有效期必须非常短,通常就是会话期间(session)有效,浏览器关掉,令牌就失效了。

密码模式(Resource Owner Password Credentials Grant)

用户向客户端提供自己的用户名和密码。客户端使用这些信息,向”服务商提供商”索要授权。

密码模式需要用户给出自己的用户名和密码,显然风险很大。这种模式在实际中应用得很少。

客户端模式(Client Credentials Grant)

指客户端以自己的名义,而不是以用户的名义,向”服务提供商”进行认证。这种模式中其实不存在用户授权这样一个环节,只需要服务提供商对客户端授权即可。

比如微信公众平台就采用了客户端模式,给平台注册的每一个客户端分配一个appid和appsecret,利用这两个东西就可以获得一个AccessToken。有了这个Token,就可以去调用接口信息了。

总结

OAuth2.0协议的核心是通过认证后获得令牌,令牌的作用就是授权进入系统的凭证。令牌与密码的授权作用类似,都是被允许进入某个系统。两者之间存在三点差异,决定了令牌相比密码授权有更大的优势:

(1)令牌是短期的,到期会自动失效。密码一般长期有效。利用令牌可以实现对第三方的短期授权,在实际场景中是普遍需要的。

(2)令牌可以被所有者撤销,并立即失效。密码一般不能撤销。

(3)令牌有权限范围。对于网络服务来说,只读令牌就比读写令牌更安全。密码一般是完整权限,在授权的灵活性上大不如令牌。

参考文章: