Oauth2.0安全认证规范(下)

发表于   |   分类于

前言

在Oauth2.0安全认证规范(上)的基础上做进一步的补充，完善对OAuth2.0授权标准规范的理解。

解决了什么问题？

oauth2.0的本质是授权，授信其他应用能够访问自身应用资源而不暴露用户账户和密码给其他应用的解决方案。

标准oauth2.0授权流程

  1. 携带oauth2.0平台分配的client_key和client_secret及自身系统回调地址redirect_uri，跳转到第三方授权页
  2. 用户在第三方授权页【例如：微信授权页】，输入第三方账号及密码授权成功后，授权系统通知浏览器重定向到redirect_uri并携带auth_code
  3. 浏览器访问redirect_uri【自身系统地址】，获取授权码【auth_code】
  4. 根据授权码获取访问码【access_token】和刷新码【refresh_token】
  5. 根据访问码【access_token】，调用授权接口获取信息等

其中，授权码【auth_code】，具有一次性【只能使用一次即失效】和时效性【10分钟内有效】;

访问码【access_token】具有时效性【一般有效时间为2小时】，且具有作用域scope，根据访问码只能访问scope范围内的接口；

刷新码【refresh_token】也是具有时效性的【大于access_token 有效期，一般为1个月】，当access_token失效后，可以通过refresh_token
重新获取一个access_token。

为什么要多一步根据授权码，获取访问码的步骤？

那是因为如果直接在redirect_uri参数中返回访问码【access_token 】，不安全，access_token可能会暴露在浏览器历史记录或访问日志中等。所以多增加了一层，在服务器端在通过auth_code获取access_token，且要保证auth_code一次性和时效性。

为什么回调地址redirect_uri中要传一个state参数？

state是由调用方生成，传给Oauth2.0授权服务器，然后由授权服务器透传回来，这样做的目的是为了防止CSRF跨站点请求伪造攻击，服务器接收到回传的state值之后，校验其是不是自己生成的，从而防止CSRF攻击。

安全防范

  1. 授权码【auth_code】,保证一次性和时效性；
    访问码【access_token】和 刷新码【refresh_token】，保证时效性，过期之后需要重新分配或重新登录授权；
  2. 访问码【access_token】的有效范围控制；
    校验client_key和client_secret有效性；
  3. 校验redirect_uri是不是白名单域名地址，防止恶意授权跳转；