OAuth 2.0 是一种广泛使用的授权框架,使第三方应用程序能够获取对 HTTP 服务上用户账户的有限访问权限。Apidog 可以根据规范直接生成 OAuth 2.0 令牌,并自动将其附加到请求中,无需在外部工具中生成令牌。授权授予类型#
OAuth 2.0 支持多种授权授予类型,每种类型都适用于不同的使用场景。请根据你的应用程序需求和 API 提供商的规范选择合适的授予类型。| 授予类型 | 使用场景 | 安全性 | 何时使用 |
|---|
| Authorization Code | 服务端 Web 应用 | 高 | Web 应用程序最常见的流程 |
| Authorization Code (With PKCE) | 移动/SPA 应用 | 非常高 | 为公共客户端提供增强安全性 |
| Implicit | 基于浏览器的应用(旧版) | 中 | 已弃用,请改用 PKCE |
| Password Credentials | 受信任的第一方应用 | 中 | 直接进行用户名/密码交换 |
| Client Credentials | 机器到机器 | 高 | 服务到服务认证 |
选择与你的 API 提供商要求相匹配的授予类型。使用错误的授予类型将导致认证失败。
配置:Authorization Code#
Authorization Code 流程是 Web 应用程序中最安全且最常用的 OAuth 2.0 流程。必填字段#
| 字段 | 描述 | 来源 |
|---|
| Auth URL | 授权端点 URL | API 提供商的 OAuth 文档 |
| Access Token URL | 令牌端点 URL | API 提供商的 OAuth 文档 |
| Callback URL | 你的应用程序重定向 URI | 你的应用程序(必须在提供商处注册) |
| Client ID | 你的应用程序标识符(App ID) | API 提供商的开发者控制台 |
| Client Secret | 你的应用程序密钥(App Secret) | API 提供商的开发者控制台 |
获取令牌#
成功获取令牌后,界面上会显示令牌内容及其有效期。当你点击 Run 按钮时,生成的令牌会自动以 Bearer 前缀附加到 Authorization 头部。令牌类型选择#
如果 OAuth 2.0 服务同时返回 Access Token 和 ID Token,Apidog 默认会使用 Access Token。若要改用 ID Token,请在 "Token Type Used" 选项中选择 ID Token。这在使用 OpenID Connect (OIDC) 实现时很有用。
令牌刷新#
切换登录账户#
OAuth 2.0 登录页面通常会记住你的登录状态。要更换账户:高级设置#
点击 Advanced 选项以配置其他 OAuth 2.0 参数。如果留空,它们将自动生成。| 设置 | 描述 | 用途 |
|---|
| Scope | 授权范围 | 限制可访问资源的范围 |
| State | 随机字符串参数 | 防止跨站请求伪造(CSRF)攻击 |
| Credentials | 如何发送客户端凭据 | Send as Basic Auth header 或 Send client credentials in body |
| Refresh Token URL | 自定义刷新端点 | 如果不同于 Access Token URL,则使用此项 |
| HTTP Authorization Prefix | 头部中的令牌前缀 | 默认值为 Bearer,可按需自定义 |
始终使用 State 参数来防止 CSRF 攻击。如果留空,Apidog 会自动生成此参数。
常见问题#
在 Apidog 中为你的 API 设置 OAuth2.0 认证时,你可能需要在授权服务器或客户端设置中注册官方重定向 URI。这可确保 OAuth 流程成功完成,并确保 Apidog 能在授权后接收访问令牌。
如果你的 API 使用 OAuth2.0 Authorization Code Flow,并且你正在配置客户端设置(例如在 OAuth 提供商或身份平台中),那么你应将此 URI 添加到 "Redirect URIs" 或 "Callback URLs" 字段中。