OAuth 白话简明教程-授权码模式(Authorization Code)

作者:vkvi 来源:ITPOW(原创) 日期:2016-11-10

OAuth 有几种模式,本文介绍最完善、最复杂、最常用的授权码模式(Authorization Code),也有人称授权码授权模式

本文中只介绍原理,不介绍具体实现,因为各大公司在应用 OAuth 时均略有不同,所以在学习 OAuth 时没必要整那么细,了解原理后,再看看各大公司的文档,自然就明白其文档所讲的意思了。

先看流程图

OAuth-授权码模式(Authorization-Code)

解释一下

  • 上图中有两个“重定向”,也就是我们说的 Response.Redirect。
  • 携带参数就是指在 URL 后面追加 QueryString。

图中有三个红色的备注。

第一个红色备注参数解释如下:

  • client_id:就是第三方应用授权服务器注册的 Id,比如现在ITPOW要做 QQ 登录接口,都必须要先在 QQ 开放平台进行注册。
  • response_type:就是说你现在想干嘛,根据后面的流程,我们知道我们是想去获取 code 值,所以这里的值固定是“code”。
  • redirect_uri:前面不是提到授权服务器还要重定向回来么?重定向哪里呢?就是这个 URL。
  • scope:想要啥权限:可以读取 QQ 个人资料?可以发 QQ 空间?具体由提供 OAuth 的服务商(比如 QQ)来决定有哪些权限字符串。
  • state:随机字符串,可以省略。第三方应用可以指定一个随机字符串,一会儿授权服务器原封不动地把这个值传回来,第三方应用一验证——嗯,这个确实是我产生的随机字符串,这个确实是我发出的登录请求。

第二个红色备注参数解释如下:

  • code:授权服务器产生的一个临时随机码(一般 10 分钟内有效,使用一次后失效),第三方应用凭这个码去换正式的 Access Token。
  • state:就是第三方应用传来的 state,原封不动传回去。

第三个红色备注参数解释如下:

  • client_id:前面说过了。
  • grant_type:注意,现在是 grant_type,不是 response_type,就是说你想要用哪种模式,本文介绍的是授权码模式,所以这里就写“authorization_code”。
  • redirect_uri:与前面的保持一致,据说服务器除了验证 code,也要验证这个是否与之前的一致(图上没画这一流程)。
  • code:前面提到过的临时随机码。

code 相当于临时令牌,Access Token 相当于长期令牌(时间由授权服务器决定),那么为什么要用临时令牌换长期令牌呢?直接给长期令牌不好么?

(令牌,名字多高大上,但其实就是一个字符串,不过数据类型虽简单,但内容很有价值,就像银行卡密码。)

要说明的是用 code 换 Access Token 并不是通过用户代理(用户代理通常是浏览器),而是第三方应用的后台代码直接向授权服务器请求的(C# 中可用 WebRequestWebClient),用户代理并不知道 Access Token 的值。这样做的好处是避免在用户代理上留下历史记录,也避免用户端中了木马后泄露 Access Token 值。

有了 Access Token 之后呢?

第三方应用可以做两类事:

  • 一类是以 QQ 帐号在第三方应用上活动。(这类其实不需要 Access Token,OAuth 其实此时只是作一个单点登录的意思。)
  • 一类是向资源服务器请求/传送资源,比如以用户的身份在 QQ 空间发布文章。(这才是 Access Token 的重要作用,它就是发布权限的凭据啊,这也是 OAuth 真正想解决的问题。)

传输安全

肯定得用 HTTPS,否则 Access Token 这种机密都被探听了(纵然没有经过用户代理,但能不保证第三方应用和授权服务器之间没人“偷听”)。

之前说过,各大公司在应用 OAuth 时有所不同,举点例呢?

我们在各大开放平台注册时,一般都有 app_id、app_secret,app_id 对应 client_id,app_secret 前面没有提,code 换 Access Token 时,有些公司要求参数中把 app_secret 也带上,有些公司却用签名(将 app_secret 混合在参数值中进行散列运算)的方式来实现。

有些就拿 Access Token 去资源服务器使用,有些却要求用 Access Token 换一个叫 Token 的东西,然后用 Token 去使用。

各大公司对参数名称的确定也不一定相同。

相关文章