细说API – 认证、授权和凭证(2)

这种基于 AK/SK 的认证方式主要是利用散列的消息认证码 (Hash-based MessageAuthentication Code) 来实现的，因此有很多地方叫 HMAC 认证，实际上不是非常准确。HMAC 只是利用带有 key 值的哈希算法生成消息摘要，在设计 API 时有具体不同的实现。

HMAC 在作为网络通信的认证设计中作为凭证生成算法使用，避免了口令等敏感信息在网络中传输。基本过程如下：

1. 客户端需要在认证服务器中预先设置 access key(AK 或叫 app ID) 和 secure key(SK)
2. 在调用 API 时，客户端需要对参数和 access key 进行自然排序后并使用 secure key 进行签名生成一个额外的参数 digest
3. 服务器根据预先设置的 secure key 进行同样的摘要计算，并要求结果完全一致
4. 注意 secure key 不能在网络中传输，以及在不受信任的位置存放(浏览器等)

为了让每一次请求的签名变得独一无二，从而实现重放攻击，我们需要在签名时放入一些干扰信息。

在业界标准中有两种典型的做法，质疑/应答算法(OCRA: OATH Challenge-Response Algorithm)、基于时间的一次性密码算法(TOTP：Time-based One-time Password Algorithm)。

质疑/应答算法

质疑/应答算法需要客户端先请求一次服务器，获得一个 401 未认证的返回，并得到一个随机字符串(nonce)。将 nonce 附加到按照上面说到的方法进行 HMAC 签名，服务器使用预先分配的 nonce 同样进行签名校验，这个 nonce 在服务器只会被使用一次，因此可以提供唯一的摘要。

基于时间的一次性密码认证

为了避免额外的请求来获取 nonce，还有一种算法是使用时间戳，并且通过同步时间的方式协商到一致，在一定的时间窗口内有效(1分钟左右)。

这里的只是利用时间戳作为验证的时间窗口，并不能严格的算作基于时间的一次性密码算法。标准的基于时间的一次性密码算法在两步验证中被大量使用，例如 Google 身份验证器不需要网络通信也能实现验证(但依赖准确的授时服务)。原理是客户端服务器共享密钥然后根据时间窗口能通过 HMAC 算法计算出一个相同的验证码。

TOTP 基本原理和常见厂商

OAuth2 和 Open ID

OAuth(开放授权)是一个开放标准，允许用户授权第三方网站访问他们存储在另外的服务提供者上的信息，而不需要将用户名和密码提供给第三方网站或分享他们数据的所有内容。

OAuth 是一个授权标准，而不是认证标准。提供资源的服务器不需要知道确切的用户身份(session)，只需要验证授权服务器授予的权限(token)即可。

上图只是 OAuth 的一个简化流程，OAuth 的基本思路就是通过授权服务器获取 access token 和 refresh token(refresh token 用于重新刷新access token)，然后通过 access token 从资源服务器获取数据 。在特定的场景下还有下面几种模式：

1. 授权码模式(authorization code)
2. 简化模式(implicit)
3. 密码模式(resource owner password credentials)
4. 客户端模式(client credentials)

如果需要获取用户的认证信息，OAuth 本身没有定义这部分内容，如果需要识别用户信息，则需要借助另外的认证层，例如 OpenID Connect。

验证 access token

在一些介绍OAuth 的博客中很少讲到资源服务器是怎么验证 access token 的。OAuth core 标准并没有定义这部分，不过在 OAuth 其他标准文件中提到两种验证 access token的方式。

在完成授权流程后，资源服务器可以使用 OAuth 服务器提供的 Introspection 接口来验证access token，OAuth服务器会返回 access token 的状态以及过期时间。在OAuth标准中验证 token 的术语是 Introspection。同时也需要注意 access token 是用户和资源服务器之间的凭证，不是资源服务器和授权服务器之间的凭证。资源服务器和授权服务器之间应该使用额外的认证(例如 Basic 认证)。

使用 JWT 验证。授权服务器使用私钥签发 JWT 形式的 access token，资源服务器需要使用预先配置的公钥校验 JWT token，并得到 token 状态和一些被包含在 access token 中信息。因此在 JWT 的方案下，资源服务器和授权服务器不再需要通信，在一些场景下带来巨大的优势。同时 JWT 也有一些弱点，我会在JWT 的部分解释。

refresh token 和 access token

几乎所有人刚开始了解 OAuth 时都有一个一疑问，为什么已经有了 access token 还需要 refresh token 呢?

授权服务器会在第一次授权请求时一起返回 access token 和refresh token，在后面刷新 access token 时只需要 refresh token。 access token 和 refresh token 的设计意图是不一样的，access token 被设计用来客户端和资源服务器之间交互，而 refresh token 是被设计用来客户端和授权服务器之间交互。

（编辑：ASP站长网）