您正在查看 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 天，或根据您需要支持的用户体验设置合适的值。