Oauth2 授权回顾

未分类

因为这周对授权模块做了些调整，特来回顾下常用的 Authorization Code Grant 的完整流程和思想。

关于 Oauth，它是一个开放标准，它提供一种方案使用户可以在不提供账户密码信息的情况下，允许第三方获取用户在某服务器存储的资源。

流程

其具体流程思路如下：
首先，Authorization Code Grant Type 允许获取 access tokens 和 refresh tokens 。

             +----------+
             | Resource |
             |   Owner  |
             |          |
             +----------+
                  ^
                  |
                 (B)
             +----|-----+          Client Identifier      +---------------+
             |         -+----(A)-- & Redirection URI ---->|               |
             |  User-   |                                 | Authorization |
             |  Agent  -+----(B)-- User authenticates --->|     Server    |
             |          |                                 |               |
             |         -+----(C)-- Authorization Code ---<|               |
             +-|----|---+                                 +---------------+
               |    |                                         ^      v
              (A)  (C)                                        |      |
               |    |                                         |      |
               ^    v                                         |      |
             +---------+                                      |      |
             |         |>---(D)-- Authorization Code ---------'      |
             |  Client |          & Redirection URI                  |
             |         |                                             |
             |         |<---(E)----- Access Token -------------------'
             +---------+       (w/ Optional Refresh Token)
Note: The lines illustrating steps (A), (B), and (C) are broken into
      two parts as they pass through the user-agent.

1. 首先 Client 把 Resource Owner 的 User-Agent 转到 authorization endpoint ，然后 Authorization Server 验证 Resource Owner 的授权
   此步骤中 Client 会把 client identifier、申请的 scope、local state 和 redirection URI 一并传给 authorization endpoint。

2. 然后 Authorization Server 会把 Resource Owner 的 User-Agent 重定向到 Client 提供的 redirection URI ，同时回传 Authorization Code
   、许可的 scope 和 local state

3. Client 就可以使用 Authorization Code 去获取 Access Token

这个流程非常适合 confidential clients 类型的 Client 使用，并且支持 Refresh Token 。

需要注意的是上边 Authorization Code 的设计：这个 code 应该是有有效期的，并且应该是单次使用有效的，如多次使用 Authorization Server 应可以失效掉
之前发放的 Access Token ，建议绑定 code、Client 和 redirection URI 三者的关系。

另外为了防止恶意篡改 Redirection URI 来欺骗 Authorization Server 错误的发放 Access Token 给未经认证及授权的 Client， Authorization Server
应该要求 Client 预设 Redirection URIs ，并在之后的请求中验证 Redirection URI 的一致性。

安全

使用过程中，有些安全问题也是要注意的。
首先就是 app_secret 的安全存储安全传输，由于 app_secret 是应用请求开放平台生成 access_token 的唯一认证，所以一定要防止 app_secret 被泄露，app_secret 可能被多种方式不经意间泄露出去：
1. app_secret 出现在页面源代码或者url中，导致直接查看源代码即获得。
2. app_secret 保存在客户端本身程序中，所有的本机应用程序，都可以反编译的代码获得。
3. 未使用HTTPS安全传输协议，攻击者通过网络嗅探获得。

然后就是 access_token，由于一般颁发的 access_token 将在一段时间内持续有效，所以应防止获取到的 access_token 被第三方窃取。不要把 access_token 保存在 cookie 或者页面代码中，攻击者攻击者可能会利用xss漏洞获取到该值。

还有就是服务器端要防范用户身份伪造攻击，一些情况下，会有需要获取用户 uid 的情况，作为同自身账号体系做关联的认证凭据，以提供更多应用自身的服务内容。

攻击者的手段多种多样，常见的： 客户端将access_token回传自身服务器，服务器提取其中的uid作为认证凭据，但并未校验该access_token的合法性。此时，通过骗取A用户授权X应用，获取 access_token 后传入Y应用服务器，便可拿到Y应用的A用户凭证，访问Y应用中该用户的服务内容。

服务器端一定要对 access_token 以及 access_token所对应的 app_key 及其来源进行有效核查，以及 access_token 中可能保存的 uid 与请求获取信息的 uid 的一致性检查，如果不符都要要求这些异常用户重新授权登录。

OAuth 2.0
facebook-login 的安全处理