您正在查看 Apigee 和 Apigee Hybrid 文档。
查看 Apigee Edge 文档。
Apigee 提供了一组工具和政策，可让您实现基于令牌的 OAuth 2.0 身份验证，以保护您的 API。OAuth2（如 IETF RFC 6749 中所述）是 API 身份验证和授权最广泛支持的开放标准。它将令牌设为客户端应用发送到 API 实现的标准格式凭据。API 实现可以验证令牌，以确定客户端是否有权访问 API。
Apigee 允许开发者通过实现四种 OAuth2 授权类型（客户端凭据、密码、隐式和授权代码）中的任意一种，使用 OAuthv2 政策生成访问权限和/或刷新令牌。 此外，API 开发者可以使用 Apigee 实现自定义授权，包括遵循令牌交换模式的授权（如 IETF RFC 8693 中所述）。 然后，客户端应用使用访问令牌来消耗安全 API。每个访问令牌都有自己的有效期，您可以在 OAuthv2 政策中设置有效期。
对于某些授权类型，Apigee 可以选择生成并返回刷新令牌以及访问令牌。在原始访问令牌被撤消或过期后，客户端会使用刷新令牌获取新的访问令牌。也可在 OAuthv2 政策中设置刷新令牌的过期时间。
反模式
在 OAuthv2 政策中为访问令牌或刷新令牌设置较长的有效期会导致在令牌泄露的情况下扩大漏洞窗口，这会带来安全风险。这还可能导致永久性存储区中积累 OAuth 令牌，从而导致性能随着时间的推移而下降。
示例 1
以下示例 OAuthV2 政策显示访问令牌的有效期为 10 天：
<OAuthV2 name="OAuth-GenerateAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>864000000</ExpiresIn> <!-- 10 days -->
<RefreshTokenExpiresIn>864000000</RefreshTokenExpiresIn> <!-- 10 days -->
<SupportedGrantTypes>
<GrantType>authorization_code</GrantType>
</SupportedGrantTypes>
<GenerateResponse enabled="true"/>
</OAuthV2>在上面的示例中：
- 访问令牌的有效期设为 10 天。
- 刷新令牌的有效期也设置为 10 天。
影响
长期有效的访问令牌会带来安全风险。如果令牌泄露或丢失，短效令牌会自然过期并变得无用，而长效令牌会在很长一段时间内继续授予对 API 的访问权限，从而增加漏洞窗口期。
访问令牌的有效期应较短，可能在 30 分钟左右或更短，并且有效期应远短于刷新令牌的有效期。
示例 2
以下示例 OAuthV2 政策显示刷新令牌的有效期为 200 天：
<OAuthV2 name="OAuth-GenerateAccessToken">
<Operation>GenerateAccessToken</Operation>
<ExpiresIn>1800000</ExpiresIn> <!-- 30 minutes -->
<RefreshTokenExpiresIn>17280000000</RefreshTokenExpiresIn> <!-- 200 days -->
<SupportedGrantTypes>
<GrantType>authorization_code</GrantType>
</SupportedGrantTypes>
<GenerateResponse enabled="true"/>
</OAuthV2>在上面的示例中：
- 将访问令牌的有效期设置为合理且较短的 30 分钟。
- 将刷新令牌的有效期设置为非常长的 200 天。
- 如果发往此 API 的流量是每秒 10 个请求，那么每天最多可以生成 864,000 个令牌。
- 刷新令牌会在 200 天后过期；它们会在整个生命周期内累积在数据存储区中。
影响
由于大量令牌会在数据存储区中累积，因此延长刷新令牌的有效期可能会导致性能随着时间的推移而下降。在 Apigee Hybrid 中，过多的令牌累积也可能会导致持久层的磁盘空间耗尽。
最佳做法
为 OAuth 访问令牌和刷新令牌使用适合您具体安全要求的有效期，以缩短令牌泄露的漏洞窗口期，并避免数据存储区中出现令牌堆积。访问令牌的生命周期最好从 30 分钟开始；刷新令牌的生命周期最好从 24 小时开始。
设置刷新令牌的有效期，使其有效期是访问令牌有效期的倍数。例如，如果您为访问令牌设置 30 分钟，则将刷新令牌的有效期设置为 24 小时或 7 天，或者根据您需要支持的用户体验设置合适的有效期。