> For the complete documentation index, see [llms.txt](https://docs.ggwp.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.ggwp.com/chinese-simplified/ggwp-ke-hu-duan-sdk/ren-zheng.md).
# 认证
GGWP SDK 支持两种认证模式：
| 认证模式 | 使用场景 | 安全性 | 环境 |
| ---- | ------- | --- | ---- |
| 静态令牌 | 快速设置与测试 | 低 | 开发 |
| 动态令牌 | 生产环境部署 | 高 | 生产环境 |
### 静态令牌
静态令牌是用于在您的应用内为各种操作启用安全访问和签名的加密密钥。这些令牌提供了一种简单直接的认证和数据完整性机制，确保 SDK 与 GGWP Server 之间的安全通信。
在此模式下，两个静态令牌——访问令牌和签名令牌，由 GGWP 生成并直接共享给客户。
数据流如下所示：
**优点**
* 无需服务器端工作
* 设置快速
#### 缺点
* 安全性较低
* 如果令牌泄露，您可能需要发布新版本（如果游戏确实有自己的令牌分发服务器）
* 所有用户发送数据都使用相同的令牌
### 动态令牌
在此模式下，GGWP SDK 使用访问令牌和刷新令牌进行安全认证和会话管理。访问令牌是用于访问受保护资源的短期令牌，而刷新令牌是用于在无需重新认证的情况下获取新访问令牌的长期令牌。
此模式要求 Services Server 构建一个 authcode-request API，该 API [发起令牌请求](#auth-code-api) 向 GGWP Server 发起请求。GGWP SDK 在初始化过程中需要此 authcode。预计 Game Client 将使用现有的、专为 Game Client 与 Services Server 之间信息交换而设计的安全协议，安全地向其自身的 Services Server 发起此 authcode 请求。初始化完成后，GGWP SDK 会负责获取并维护访问/刷新令牌。
数据流如下所示：
#### ***优点***
* 令牌生命周期短，并与用户绑定。若发生泄露，影响会被隔离，且仅在较短时间内受限
* 令牌会被安全地临时存储，且难以被提取
* 可远程撤销
#### ***缺点***
* 要使其工作，服务器端也需要进行开发
#### 认证代码 API
此步骤在 Services Server 与 GGWP Server 之间通过一个 `x-api-key` 请求头进行认证。您将收到一个 authcode，该 authcode 仅在 5 分钟内有效，并可兑换为一个临时访问令牌。
**参数**
`请求头`
* x-api-key：与您的组织和仪表板对应的 GGWP API 密钥。
`请求体`：包含以下字段的字典：
* user\_id：已登录玩家或用户的唯一标识符
* scope：会话所需权限的数组。有效值为 `write:voice`, `write:chat`, `write:reports` 和 `write:discord`
```bash
curl --request POST "https://client-api.ggwp.com/auth/v1/authorize" \\
--header 'x-api-key: ' \\
--data-raw '{
"user_id": "用户 ID",
"scope": ["write:voice", "write:chat"]
}'
```
**输出**
* 200 - 操作成功
```json
{
"code": "00000000-0000-0000-0000-000000000002.1bea101b-12d2-47c4-9407-0fbae3ab7691"
}
```
* 400
* 错误请求：表示请求包含不正确或格式错误的数据。
* 403
* **禁止访问**：表示服务器理解该请求，但拒绝对其进行授权。
* 这可能是由于令牌无效、user\_id 不匹配，或者
* 当超过速率限制时
* 500
* **内部服务器错误**：表示服务器遇到意外情况，导致无法完成请求。