想在应用中添加安全的 OAuth2 对您的 Capacitor Capacitor
app?以下是快速入门指南。 Capacitor apps __CAPGO_KEEP_0__ @capgo/capacitor-social-login @__CAPGO_KEEP_0__/__CAPGO_KEEP_1__-social-login @capgo/capacitor-passkey @code/__CAPGO_KEEP_1__-passkey
保持浏览器风格的WebAuthn __CAPGO_KEEP_0__,而原生密码登录调用则由系统处理。另外,它还会使用令牌而不是存储敏感凭证来保持您的应用程序安全。 Capacitor app 在 5 步中:
- 设置您的 OAuth2 提供商: 选择提供商(例如,Google, Auth0), 配置重定向 URI,安全地管理客户端凭证。
- 安装和配置 OAuth2 插件: 添加插件,或者使用
@byteowls/capacitor-oauth2@__CAPGO_KEEP_0__/__CAPGO_KEEP_1__-social-login @capgo/capacitor-social-login 对于 iOS,Info.plist对于 Android)。AndroidManifest.xmlprotectedTokens - 构建认证流程: 使用插件安全地处理用户登录、令牌存储和注销。启用 PKCE : 为额外保护
- 测试跨平台: 在 iOS、Android 和 web 浏览器上验证流程。修复常见问题,如重定向 URI 匹配错误或 PKCE 错误。
- 安全实施: 在安全存储中存储令牌(Keychain/Keystore),使用 HTTPS,并设置强大的 内容安全策略.
快速比较:安全令牌存储选项
| 存储选项 | 最佳选择 | 安全级别 | 离线访问 | 示例用例 |
|---|---|---|---|---|
| 安全存储 | 移动应用 | 高 | 是 | 刷新令牌 |
| 内存存储 | 临时访问 | Medium | 否 | 活跃访问令牌 |
| HttpOnly Cookies | Web 应用 | 高 | 是 | 基于浏览器的会话 |
如何使用 Capacitor Capacitor 到您的 App

第 1 步:设置您的 OAuth2 提供者
正确设置 OAuth2 提供者是实现 OAuth2 的第一步和最关键的步骤。它涉及选择与您的应用需求相匹配的提供者,配置技术细节,如重定向 URI,安全地处理您的凭据。这些步骤为接下来安装 OAuth2 插件做好准备。
选择 OAuth2 提供者
首先选择一个与您的应用功能、安全需求和兼容性相匹配的 OAuth2 提供者。您正在构建的应用类型会影响 OAuth 2.0 流程,这直接影响您的提供者选择 [2]对于基于 Capacitor 的应用,建议使用 Authorization Code 流程与 PKCE - 这是移动应用的首选方法。
比较提供者时,重点关注其安全功能。寻找像签名 cookie、CSRF token 验证和加密 JWT 等选项。如果您的应用处理敏感数据,支持多因素身份验证 多因素身份验证 在Capacitor应用中实施OAuth2必须遵循一定的步骤。评估时,应根据您的需求平衡成本和功能,而不陷入繁琐的比较中。
配置重定向URI
重定向URI至关重要,它们告知OAuth2提供者在用户完成身份验证后应该将用户发送到哪里。正确配置这些URI确保在移动和Web平台上都能实现顺畅的体验。
对于移动应用,应使用自定义URL方案,通常以 com.example.app://callback,其中 com.example.app 匹配您的应用包ID。对于Web应用,应使用 window.location.origin 作为重定向URI。如果您正在测试本地环境,URL http://localhost:8100/callback 会很好地工作。
对于iOS用户,请注意Capacitor的浏览器插件使用 SFSafariViewController。从iOS 11开始,这不会与Safari共享Cookie,这可能会影响单点登录功能。如果SSO是必需的,请考虑使用支持 ASWebAuthenticationSession [3].
管理客户端凭证
客户端凭证用于识别您的应用程序并向 OAuth2 提供者发送请求。它由客户端 ID 和客户端密钥组成。客户端 ID 可以看作是公开标识符,而客户端密钥应该像私钥一样对待。
请勿将客户端密钥直接硬编码到您的应用程序中或提交到版本控制中。相反,使用环境变量或安全密钥管理系统来存储它们。此外,优先选择短期令牌和最小权限,以限制暴露并提高安全性。
步骤 2:安装和配置 OAuth2 插件
Now that your OAuth2 provider is ready, the next step is to add the plugin to your Capacitor app and set it up for iOS, Android, and web platforms.
安装插件
该 @byteowls/capacitor-oauth2 plugin works with most OAuth2 providers. To avoid compatibility issues, you’ll need to install the version that matches your Capacitor setup.
Here are the installation commands based on your Capacitor version:
- Capacitor v5:
npm i @byteowls/capacitor-oauth2 - Capacitor v4:
npm i @byteowls/capacitor-oauth2@4 - Capacitor v3:
npm i @byteowls/capacitor-oauth2@3
安装完成后,运行同步命令(”,”)来更新本机依赖项。这一步骤对于确保插件正确与iOS和Android项目集成至关重要。如果跳过此步骤,编译移动平台时可能会出现构建错误。npx cap sync配置插件设置
安装完成后,您需要配置插件以匹配OAuth2提供者的设置。这可以通过调用”方法中的”对象来完成。需要定义的关键参数包括:
appId oauth2Options : OAuth2提供者的客户端ID。 authenticate() authorizationBaseUrl
- : OAuth2提供者的授权端点。responseType
- : 通常设置为__CAPGO_KEEP_0__
- __CAPGO_KEEP_1____CAPGO_KEEP_2__
"code"为移动应用程序而设计。 - 重定向 URL: 这必须与步骤 1 中配置的重定向 URL 匹配。
您还可以设置其他参数,如 accessTokenEndpoint, scope,以及平台特定的选项,以微调身份验证过程。
对于 Android,更新您的 AndroidManifest.xml 和 strings.xml context Info.plist Page/area: Capgo marketing website. Role: Short UI label or navigation item. Seen in: page trust.astro. Message key `and` (And).
Check Capacitor Version Compatibility
It’s essential to verify that the plugin version matches your Capacitor version. Mismatched versions can cause build errors or runtime issues. The @byteowls/capacitor-oauth2 检查Capacitor版本兼容性
| 插件版本 | 兼容的Capacitor版本 | 注意 |
|---|---|---|
| 5.x | 5.x.x | 需要 Xcode 14.1. changelog中有说明的重大变化。 |
| 4.x | 4.x.x | 需要Xcode 12.0. changelog中有说明的重大变化。 |
| 3.x | 3.x.x | 需要 Xcode 12.0。请参阅 changelog 中的更改记录。 |
| 2.x | 2.x.x | 需要 Xcode 11.4。请参阅 changelog 中的更改记录。 |
| 1.x | 1.x.x |
如果您正在开发 iOS 应用,请注意 Xcode 版本要求。使用不兼容的版本会阻止您的应用成功构建。插件文档包含详细的兼容性表格,这些表格是解决版本相关问题的宝贵资源。
如果安装后遇到问题,请卸载当前插件版本,安装适合您的 Capacitor 版本的正确插件,然后再次运行同步命令。这比尝试强制不兼容的版本工作更有效。
步骤 3:构建 OAuth2 认证流程
已配置插件后,接下来是创建一个功能齐全的认证流程。这一步确保了安全的用户登录、令牌管理和注销,使您的应用能够在多个平台上管理用户会话。
创建登录流程
登录流程从调用 authenticate() 使用一个选项对象开始。这个对象应该包含你的 authorizationBaseUrl, redirectUrl和设置 responseType 设置为 'code' 以符合 PKCE 要求。该插件安全地打开提供者的登录页面,用户可以输入他们的凭据。登录成功后,提供者会将用户重定向回你的应用程序,带有令牌和用户详细信息。
最好的部分是:用户直接在 OAuth2 提供者那里输入凭据,所以你的应用程序永远不会访问敏感信息。该方法返回一个包含访问令牌、刷新令牌和用户数据(如电子邮件或个人资料详细信息)的响应对象。
在 iOS 和 Android 平台上,这个过程使用一个安全的 web 视图,共享 cookie 与系统浏览器。 在 web 平台上,它依赖于标准的浏览器重定向。正确配置你的重定向 URL 确保无论平台如何都能提供smooth 用户体验。
处理令牌存储和刷新
用户登录后,安全地管理令牌是你的下一个优先事项。这包括安全地存储令牌并自动刷新令牌以避免会话中断。这里是如何处理它:
- 访问令牌: 在内存中存储这些令牌,以便快速和临时访问。
- 刷新令牌: 使用安全存储,例如
capacitor-secure-storage插件,使用AES-256对令牌进行加密,通过iOS Keychain或Android Keystore 。 这样即使设备被破坏,令牌也会得到保护。当您的应用程序重新启动时,检查存储的令牌以便用户在不需要重新输入凭据的情况下重新登录。
存储方法
| 安全级别 | 性能 | 离线访问 | 最佳用例 | 安全存储 |
|---|---|---|---|---|
| AES-256硬件加密 | __CAPGO_KEEP_0__ | Medium | 是 | 长期数据 |
| 内存存储 | 高(临时) | 高 | 否 | 活跃访问令牌 |
| 常规存储 | 低 | 高 | 是 | 非敏感偏好 |
为了保持会话活动,务必在令牌过期之前刷新令牌。 在进行API调用之前,检查访问令牌是否即将过期。如果是,使用刷新令牌从您的OAuth2提供商那里获取一个新的访问令牌。 为提高可靠性,包括逻辑以在网络重新连接时重试令牌刷新。如果刷新令牌已过期或被撤销,请将用户重定向回登录流以重新验证。
添加注销功能
安全有效的注销流程同样重要。首先通过提供商的端点来撤销刷新令牌。然后清除令牌从安全存储中并重置用户数据以确保所有会话都已终止。
仅仅删除本地令牌是不够的。 OAuth2提供商通常维护服务器端会话,这些会话可能会自动重新验证用户。撤销刷新令牌会打断与授权许可证相关的令牌链,从而确保存储的凭证不能被重用。
“JWT访问令牌无法撤销。它们有效直到过期。由于它们是持有者令牌,因此无法使其失效。” – lihua.zhang,Auth0员工 [5]
为了撤销令牌,请在清除本地存储之前调用提供商的令牌撤销端点并使用刷新令牌。 这个服务器端操作可以防止令牌滥用,即使凭证已被泄露。 在撤销令牌之后,清除令牌从安全存储中,重置缓存的用户数据,并将用户导航回登录屏幕。
对于单一登录(SSO)设置,决定是否应在注销时结束使用相同提供者的其他应用程序的会话。此外,确保注销过程在网络中断时能顺利进行,通过在本地存储注销请求并在连接恢复时重试它们来实现。这确保了在提供者端进行了适当的清理。
步骤 4:测试 OAuth2 集成
在设置 OAuth2 配置并开发身份验证流程之后,下一步是进行彻底的测试。这确保了您的集成在设备和平台之间无缝工作,提供可靠的用户体验。测试涉及在移动设备和 web 浏览器上验证功能,同时也要识别并解决在发布应用之前的潜在问题。
在 iOS 和 Android 设备上测试
首先在物理 iOS 和 Android 设备上测试整个身份验证过程。
-
对于 iOS: 确保 URL 方案在文件中正确配置,并确认您的应用程序正确处理来自 OAuth2 提供者的重定向。避免使用
Info.plist,因为这可能导致错误。相反,使用像 Google Sign-In for iOS 或 OpenID Foundation 的 AppAuth for iOS 这样的库来有效地处理身份验证流程WKWebView对于 Androiddisallowed_useragent: 确保您的 [6]. -
For Android: Check that your
AndroidManifest.xml包含了正确的意图过滤器来处理重定向 URI。与 iOS 类似,避免使用android.webkit.WebView用于授权请求,因为这也可能导致disallowed_useragent错误。对于 Android,优先使用 Google Sign-In 或 OpenID AppAuth 等库 [6].
在两种情况下,测试错误场景,如授权服务器不可用 [7]。如果您的应用程序请求多个权限(范围),请验证哪些已被授予,并处理某些可能被拒绝的情况 [6].
测试 Web
对于 Web 平台,使用开发工具监视网络请求并确保令牌安全。工具如 OAuth 2.0 Playground 可以帮助您测试流程 [10],而 HTTP 拦截代理如 ZAP 或 BurpSuite 可以在测试中提供更深入的见解 [11].
在测试时,使用Authorization Code授权码与PKCE,作为公共客户端的推荐方法。确保通过POST参数或头部值安全地传输机密信息,而不是通过URL参数。 Referrer-Policy 以增强保护 [11].
解决常见问题
在测试过程中,您可能会遇到需要解决的问题:
-
错误的重定向URI:重定向URI不匹配通常会导致“未授权客户端”错误。确保重定向URI在OAuth2提供商的设置、__CAPGO_KEEP_0__应用中的文件和原生平台清单中完全匹配。
capacitor.config.jsonfile in your Capacitor app, and the native platform manifests.PKCE验证错误 [8]
-
:确认PKCE支持和配置正确,因为它对于安全您的应用程序至关重要插件实现错误 [9].
-
:错误,如“iOS上未实现插件”通常表明缺少配置或__CAPGO_KEEP_0__环境中的问题。启用OAuth2插件的日志,以帮助识别和解决这些问题: Errors like “Plugin is not implemented on iOS” typically indicate missing configurations or issues within the Capacitor environment. Enable logging in your OAuth2 plugin to help identify and resolve these problems [4].
-
状态不符错误: 如果授权请求中的状态参数与重定向响应中的状态参数不匹配,可能存在安全风险。特别是在使用自定义 OAuth 处理器(如 Facebook)时,需要小心检查自定义处理器 code 以确保没有错误或配置错误 [4].
步骤 5:安全实施 OAuth2
保护 OAuth2 集成至关重要,以保护敏感数据并降低漏洞。以下是确保您的实施保持安全的关键实践
启用 PKCE 提高安全性

One of the most effective ways to secure your authorization flow is by enabling PKCE (Proof Key for Code Exchange). PKCE helps prevent unauthorized interception of authorization codes. Here’s how it works:
- 首先生成一个随机
code_verifier长度在 43 到 128 个字符之间 - 然后创建一个
code_challenge通过使用SHA-256并将结果以base64 URL格式编码code_verifier如果您正在使用
插件,启用PKCE非常简单。以下是示例配置: capacitor-community/generic-oauth2 此插件自动处理PKCE,并且不支持__CAPGO_KEEP_0__流程。
{
responseType: "code",
pkceEnable: true,
redirectUrl: "com.companyname.appname:/"
}
This plugin automatically handles PKCE and does not support the Code Flow without it. The code_challenge_method 使用安全存储的令牌 [12].
安全存储OAuth2令牌至关重要,以防止未经授权的访问。对于原生移动应用程序,请利用操作系统提供的安全存储:
在iOS上使用
- Keychain 以硬件加密和OS级别保护 在Android上使用
- KeyStore 密钥库, 也可以支持 生物识别验证 提高安全性。
对于 Web 应用程序, HttpOnly 安全 cookie , SameSite 以减轻跨站点脚本 (XSS) 风险。
以下是安全存储选项的快速比较:
| 存储选项 | 最佳用途 | 安全性优势 | 注意事项 |
|---|---|---|---|
| iOS Keychain | 原生iOS应用 | 硬件加密和操作系统级保护 | 需要平台特定的实现 |
| Android Keystore | 原生Android应用 | 安全存储,可能具有生物识别保护 | 设备安全功能有所不同 |
| HttpOnly Cookies | Web浏览器 | 抵抗XSS和安全的自动传输 | 必须在同域名下配置API |
| 前端后端 | 所有平台 | 令牌不会暴露给客户端 | 需要额外的服务器基础设施 |
为了提高安全性,请考虑使用短期令牌和加密存储。例如,Auth0 将活跃刷新令牌限制为每个用户每个应用程序200个,以减少风险 [13]您还可以通过使用HttpOnly cookie的后端前端代理来增强安全性 [14].
设置内容安全策略
除了安全存储之外,实施强大的内容安全策略(CSP)可以帮助保护您的应用程序免受跨站点脚本(XSS)和code注入等攻击。您可以使用HTTP头或在HTML中添加一个 Content-Security-Policy 标签来配置CSP <meta> 需要重点关注的关键指令包括:
Key directives to focus on include:
- default-src: 设置所有内容类型的fallback规则。
- script-src: 控制哪些JavaScript文件允许执行。
- connect-src: 管理API调用和OAuth2交互。
- frame-ancestors: 防止点击劫持通过限制谁可以在iframe中嵌入您的应用。
为了最大限度地提高保护,使用严格的nonce或哈希代替广泛的allowlist,并避免像 unsafe-inline 或 unsafe-eval(HTML文本片段来自更长的Capgo UI字符串(父级键`alternatives_cta_questions`)。页面/区域:Capacitor live-update alternatives比较页面。角色:长期营销或法律段落。见于:页面alternatives.astro。保留Capgo产品/品牌和开发者术语完全不变。消息键`alternatives_cta_questions`(Alternatives CTA Questions)。 | HTML文本片段来自更长的Capgo UI字符串(父级键`appflow_cta_questions`)。页面/区域:Appflow比较/迁移营销复制。角色:长期营销或法律段落。见于:页面ionic-appflow.astro。保留Capgo产品/品牌和开发者术语完全不变。消息键`appflow_cta_questions`(Appflow CTA Questions)。 | HTML文本片段来自更长的Capgo UI字符串(父级键`capwesome_cta_questions`)。页面/区域:Capawesome比较页面。角色:长期营销或法律段落。见于:页面capwesome.astro。保留Capgo产品/品牌和开发者术语完全不变。消息键`capwesome_cta_questions`(Capwesome CTA Questions)。 | HTML文本片段来自更长的Capgo UI字符串(父级键`consulting_faq_subtitle`)。页面/区域:咨询服务页面。角色:段落标题或标语。见于:页面consulting.astro。保留Capgo产品/品牌和开发者术语完全不变。消息键`consulting_faq_subtitle`(Consulting FAQ Subtitle)。 | 页面/区域:Appflow比较/迁移营销复制。角色:短UI标签或导航项。见于:页面ionic-appflow.astro,页面ionic-enterprise-plugins.astro,页面解决方案/ionic-enterprise-plugins.astro。消息键`appflow_plugins_or`(Appflow Plugins Or)。 upgrade-insecure-requests . 如果您的应用正在从HTTP转换到HTTPS,请考虑添加指令。要确保您的OAuth2内容不能被嵌入到其他地方,请设置 frame-ancestors 'none'.
结论和下一步
关键点
您已经成功在您的Capacitor应用中实现了OAuth2身份验证,通过遵循五个核心步骤。这些步骤包括设置OAuth2提供商、安装所需的插件、创建身份验证流程、在多个平台上测试以及使用PKCE和适当的令牌存储来安全地集成。请记住,OAuth 2.0是一个 授权协议而不是身份验证协议 [1].它的主要重点是授予访问权限,而不是验证用户身份。
安全性至关重要,尤其是对于移动应用。使用OAuth 2.0的组织报告了与依赖基本身份验证方法的组织相比,API访问安全事件的34%降低 [19].通过采用最佳实践,如使用短期访问令牌、实现PKCE和安全存储令牌,您已经为应用的身份验证系统奠定了坚实的基础。
现在,您可以探索如何在保持安全框架的同时扩展应用的功能。
添加更多功能
在OAuth2的基础上,您有机会通过添加更多功能来增强应用。例如:
- OpenID Connect OAuth 2.0: OAuth 2.0扩展用户认证和单点登录(SSO)功能 [16].
- 多因素认证(MFA): 增加安全保护的额外层 [17].
- 渐进式资料收集: 提高用户体验和注册体验 [15].
考虑使用以下工具进行持续维护和更新 Capgo,它允许您实时推送更新、修复和新功能 - 无需等待应用商店批准。这对于处理安全补丁或快速推出新认证功能尤其有用。
更多资源
为了进一步增强OAuth2实现,利用以下资源和策略:
-
API 网关安全: 加强部署安全性,通过实施身份验证和授权措施、缓存、以及强大的日志和分析功能 [20].
-
Aaron Parecki的建议: 根据Aaron Parecki的建议, OAuth 2.0简化:
“The Authorization Code Flow is the most secure of the OAuth 2.0 flows and should be used whenever possible for server-side applications” [18].
以下是快速参考表,指导您下一步的行动:
| 阶段 | 重点领域 |
|---|---|
| 系统配置 | 管理令牌生命周期、强制HTTPS、安全存储敏感信息 |
| 令牌管理 | 使用短期访问令牌并轮换刷新令牌 |
| 验证过程 | 验证签名并检查令牌过期 |
通过定期安全审计并保持最新的实现来保持领先。例如,OAuth 2.1 引入了改进,如要求 PKCE 对所有授权 code 请求和淘汰较少的安全流 [19].此外,Capacitor 文档和 OAuth2 插件仓库提供了持续的技术支持,以帮助维护和改进您的应用程序的身份验证系统
常见问题
::: faq
为什么我应该使用 OAuth2 在移动应用程序中使用 Authorization Code 流程和 PKCE?
为什么使用 Authorization Code 流程和 PKCE 在移动应用程序中?
Authorization __CAPGO_KEEP_0__ 流程和 PKCE 是移动应用程序的首选选择,因为它通过解决授权 Code 拦截和中间人攻击等风险来提高安全性。 PKCE(证明密钥交换)通过添加额外的保护层来工作:它要求授权服务器验证一个唯一的 __CAPGO_KEEP_2__ 挑战。这确保了只有预期的应用程序才能完成身份验证过程 is a go-to choice for mobile apps because it boosts security by addressing risks like authorization code interception and man-in-the-middle attacks. PKCE (Proof Key for Code Exchange) works by adding an extra layer of protection: it requires a unique code challenge that the authorization server validates. This ensures that only the intended app can finalize the authentication process.
__CAPGO_KEEP_0__
::: faq
如何在iOS、Android和Web应用中安全存储OAuth2令牌?
为了在不同平台上安全存储OAuth2令牌,使用 每个平台的安全存储解决方案对于iOS,Keychain Services是首选选项,而Android用户应该依赖Android Keystore系统。这些工具专门设计用于保护敏感数据,包括令牌。对于Web,安全cookie或加密浏览器存储可以作为有效的替代方案。
添加加密,如AES-256,令牌的安全性又增加了一层。使用 短期令牌 并在需要时安全刷新它们进一步降低了风险。实现 PKCE (Proof Key for Code Exchange) 在OAuth2流程中是阻止未经授权访问的聪明做法。为了获得更强的保护,考虑将生物识别身份验证集成到存储令牌的应用中,确保只有合法的用户才能访问存储的令牌。 :::
::: faq
在Capacitor应用中测试OAuth2集成时最常见的问题是什么,如何解决?
当在Capacitor应用中测试OAuth2集成时,开发者可能会遇到几个常见的问题。以下是需要注意的内容:
- 无效的客户端凭证: 确保您的客户端ID和密钥设置正确,并与OAuth提供商的配置详细信息匹配。即使是小的拼写错误也可能导致问题。
- 重定向URI不匹配: 应用程序中的重定向URI必须与OAuth提供商中注册的URI完全匹配。请仔细检查以避免不必要的麻烦。
- 令牌过期: 令牌不会永远存在。设置可靠的令牌刷新系统来处理过期令牌,保持用户体验不受影响。
- 权限配置不正确: 应用程序中请求的权限需要与OAuth提供商中配置的权限匹配。权限不匹配可能导致意外错误。
要解决这些问题,请花时间彻底检查应用程序的OAuth设置。实现强大的错误处理来捕获和解决问题,测试您的身份验证流程在不同场景下。工具如Capgo可以使开发更高效,用户更满意,因为您可以直接将更新和修复推送到应用程序,而无需等待应用商店批准。
继续阅读:5步实现Capacitor应用中的OAuth2
如果您正在使用 5 步实现 OAuth2 在 Capacitor 应用中的步骤 为了规划安全性和合规性,连接它 加密 加密 合规性 合规性 Capgo 安全扫描器 Capgo 安全扫描器 Capgo 安全 Capgo 安全 Capgo 信任中心 Capgo 信任中心