OAuth Faq

概述

本篇整理 OAuth 一些常见问题供大家参考。

为什么需要 Authorization Code

完整的问题是为什么要 authorization code，为什么不直接给 accessToken？这样不是更方便吗？回答这个问题之前我们先简单介绍下授权码模式，授权码模式的第一步就是将用户导向认证服务器的某个端点（Endpoint）认证用户身份，一般上这个端点类似以下这样：

GET /authorize?response_type=code&client_id=b7BhdVkqt3&state=abc&redirect_uri=https://www.some-third-party-app/auth/callback HTTP/1.1
Host: auth.server.com

从端点中可以看出，有个 client_id 参数，这是三方 app 的身份标识，需要预先注册到认证服务器上。当用户在该端点完成自己的认证并确认授权后，浏览器会重定向到 redirect_uri 指定的地址，注意这个 redirect_uri 需要进行 url 编码，这里为了方便大家阅读，因此没有编码。实际上经过编码后的 redirect_uri 长下面这样：

https%3A%2F%2Fwww.some-third-party-app%2Fauth%2Fcallback

注：不知道怎么进行 url 编码的同学，可以使用这里的在线工具编码完成编码。

当用户完成认证并确认授权第三方 app 后，会重定向到 redirect_uri 指定的地址，并带上授权码（code），像下面这样：

https://www.some-third-party-app/auth/callback?code=123abc

第三方 app 拿到授权码后，使用自己的 client_id、client_secret 和 code 换取 accessToken。这一步认证了第三方 app，确保了这个 code 确实是颁发给 client_id 指定的第三方 app。

所以这个问题的答案就是为了安全，第一步获取授权码是从浏览器（即用户代理）发起的，浏览器是没有第三方 app 的 client_secret 的，如果将 client_secret 放到 /authorize 端点中，可能会导致 client_secret 泄露，造成安全问题。第二步则是为了认证第三方 app，确保 code 不会被其他未经用户授权的 app 使用。

为什么需要 Access Token 和 Refresh Token

• access token 一般时短期的，而 refresh token 相对时间较长。如果不幸泄露了 access token，那么黑客也只能使用有限的时间。
• 问题是如果 access token 不幸泄露，那么 refresh token 就能够幸免吗？假如 refresh token 也泄露了，那么会怎样？答案是不怎样，因为仅有 refresh token 是无法刷新 access token 的，需要 access token+appid+app secret。

除了以上两点，还有一点是出于安全考虑：

There is a security reason, the refresh_token is only ever exchanged with authorization server whereas the access_token is exchanged with resource servers. This mitigates the risk of a long-lived access_token leaking in the "an access token good for an hour, with a refresh token good for a year or good-till-revoked" vs "an access token good-till-revoked without a refresh token."